lustre-devel-lustre.org archive mirror
 help / color / mirror / Atom feed
From: Christian Kuntz <c.kuntz@opendrives.com>
To: Andreas Dilger <adilger@whamcloud.com>
Cc: Lustre-devel <lustre-devel@lists.lustre.org>
Subject: Re: [lustre-devel] Testing 2.14 on Debian + ZFS
Date: Fri, 19 Feb 2021 01:11:06 -0800	[thread overview]
Message-ID: <CANdLGj7o4yJf3byyM4LaAm+ZfNkAswTjU+HSUeK2yK+Yw4cvVg@mail.gmail.com> (raw)
In-Reply-To: <477F0D07-A7E1-488A-8E06-FE6C2E748FE1@whamcloud.com>


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

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>
wrote:

> On Feb 12, 2021, at 16:07, Christian Kuntz <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: 5911 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

  reply	other threads:[~2021-02-19  9:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12 23:07 [lustre-devel] Testing 2.14 on Debian + ZFS Christian Kuntz
2021-02-18 11:09 ` Andreas Dilger
2021-02-19  9:11   ` Christian Kuntz [this message]
2021-02-19 14:17     ` Spitz, Cory James
2021-02-19 20:12     ` Andreas Dilger
2021-02-20  3:00       ` Christian Kuntz
2021-02-22 19:58         ` Faaland, Olaf P. via lustre-devel
2021-02-23  3:41           ` Christian Kuntz via lustre-devel
2021-08-23  1:59             ` Christian Kuntz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANdLGj7o4yJf3byyM4LaAm+ZfNkAswTjU+HSUeK2yK+Yw4cvVg@mail.gmail.com \
    --to=c.kuntz@opendrives.com \
    --cc=adilger@whamcloud.com \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).