[lustre-devel] Testing 2.14 on Debian + ZFS

[Christian Kuntz]

Thanks for your time and the thoughtful response.

Looking at this a bit more, it seems to be caused by the recent ZFS 2.0
changes for linux and freebsd support, namely the `include/os/linux` paths
that provide `<sys/types.h>` that ZFS is trying to use. Adding them into
the includes for the osd-zfs directory has fixed the references being
broken, and now I'm contending some redefinitions and argument type
mismatches. I'll try and sort this out, in the meantime is there a better
place for me to place messages about this? I know this mailing list isn't
used very frequently and I'd hate to flood it with such off-the-beaten-path
stuff.

Best,
Christian

On Thu, Feb 18, 2021 at 3:09 AM Andreas Dilger <adilger at whamcloud.com>
wrote:

> On Feb 12, 2021, at 16:07, Christian Kuntz <c.kuntz at opendrives.com> wrote:
>
>
> Hello,
>
> I hope I'm communicating in the right place here, I'm currently working to
> compile Lustre 2.14.0-RC2 on Debian 10.7 with ZFS 2.0.2 for OSDs. If
> there's anything I can do to help with the testing effort or help Lustre's
> Debian support be more robust, please let me know! I hope I'm not too late
> in the release cycle to contribute.
>
>
> Thanks for the offer of testing.  Unfortunately we are very late in the
> 2.14.0 release cycle (we are hoping to make the final release in the next
> week or so, barring any critical defects).  However, even if any changes
> miss the final 2.14.0 release, having patches available to fix any issues
> you run into will make it easier for the next person to build on Debian.
>
> Ideally, any required fixes for Debian building should go into the Lustre
> tree directly rather than into a separate "downstream" package, so that
> "make debs" works out-of-the-box.  We do build Ubuntu 18.04 and 20.04
> clients regularly, and ZFS 2.0 servers on RHEL7/8, but I don't know if
> anyone is building the server code on Debian/Ubuntu on a regular basis.
>
> On the topic of compiling, I'm currently working to get debian packages
> made and running into a compilation issue that didn't seem to present on my
> previous endeavors with 2.13 and 0.7. I've got the kernel and zfs locally
> built and their packages made, and lustre's configure step successfully
> completes, but when it comes to compiling it appears that the osd-zfs
> portion has some broken include links:
>
> In file included from /zfs-linux-2.0.2/include/sys/arc.h:32,
>                  from /lustre-debian/lustre/osd-zfs/osd_internal.h:51,
>                  from /lustre-debian/lustre/osd-zfs/osd_handler.c:52:
> /zfs-linux-2.0.2/include/sys/zfs_context.h:45:10: fatal error:
> sys/types.h: No such file or directory
>  #include <sys/types.h>
>
> For reference, my configure and make looks like:
> ./configure --with-linux=/linux-4.19.171-2/  \
>
>  --with-linux-obj=linux-4.19.171-2/debian/build/build_amd64_none_amd64 \
>              --with-zfs=/zfs-linux-2.0.2 \
>               --enable-server --enable-modules --disable-ldiskfs
> make -j"$(nproc)" debs
>
>
> From the error and some probing, it looks like zfs_context.h expects some
> header files to be in their libc standard `/usr/include/sys` (or somewhere
> abouts), but lustre's make process is pulling them from the linux sources
> in `SRC/include/linux/`. Predictably, I found this out the hard way by
> adding `-I/usr/include` to the Makefile for the zfs osds and getting
> battered with errors and warnings about duplicate definitions.
>
>
> It may be that you are looking at this from the wrong angle.  Rather than
> trying to include more userspace headers, it might be worthwhile to see why
> <sys/arc.h> is being included by osd_internal.h and maybe there is a more
> appropriate header that could be used in the kernel?  Failing that, it
> isn't clear wh zfs_context.h is including the <sys/type.h> header from
> userspace when building with __KERNEL__ set?  Kernel code should be using
> <linux/types.h>.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Lustre Architect
> Whamcloud
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20210219/60afff37/attachment.html>