Re: [lustre-devel] Testing 2.14 on Debian + ZFS

["Spitz, Cory James" <cory.spitz@hpe.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4321 bytes --]

Hello!

>  I know this mailing list isn't used very frequently and I'd hate to flood it with such off-the-beaten-path stuff.

No worries, Christian.  Any related devel topics are welcome here.  You are in the right place!

-Cory

On 2/19/21, 4:11 AM, "lustre-devel" <lustre-devel-bounces@lists.lustre.org> wrote:

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@whamcloud.com<mailto:adilger@whamcloud.com>> wrote:
On Feb 12, 2021, at 16:07, Christian Kuntz <c.kuntz@opendrives.com<mailto:c.kuntz@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






[-- Attachment #1.2: Type: text/html, Size: 9179 bytes --]

[-- Attachment #2: Type: text/plain, Size: 165 bytes --]

_______________________________________________
lustre-devel mailing list
lustre-devel@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org