Issues when compiling OpenZFS 2.0.0 on debian buster

[Binarus]

Dear all!

System information

Type | Version/Name
Linux | debian
Distribution Name | debian
Distribution Version | buster (10.7)
Linux Kernel | 4.19.0-12
Architecture | amd64
ZFS Version | OpenZFS 2.0.0
SPL Version | (SPL integrated into OpenZFS 2.0.0)

Describe the problem you're observing

We are running some debian buster boxes on ZFS here. Since we had massive performance problems with ZFS ZVOLs, we decided to remove ZFS version 0.7.12, which is what debian buster incorporates, and install OpenZFS 2.0.0 as a test.

At first, we'd like to thank the developers for the software and for the documentation, notably the building howto. We have literally followed the howto, with one exception: Instead of cloning the repository, we used the tarball, because we wanted an official release (2.0.0) instead of the newest version.

The build went surprisingly well, and we now can boot buster from a ZFS mirror with OpenZFS 2.0.0. However, during build, we noticed two small issues which may or may not turn into problems some day - I am not deep enough into the matter to judge it:

1. We got a bunch of warnings like the following:

ar: `u' modifier ignored since `D' is the default (see `U')

My personal guess is that we can safely ignore these warnings.

2. We got the following three warnings:

/install/zfs-2.0.0/module/icp/asm-x86_64/sha1/.tmp_sha1-x86_64.o: warning: objtool: sha1_block_data_order()+0x11: unsupported stack pointer realignment
/install/zfs-2.0.0/module/icp/asm-x86_64/sha2/.tmp_sha256_impl.o: warning: objtool: SHA256TransformBlocks()+0x19: unsupported stack pointer realignment
/install/zfs-2.0.0/module/icp/asm-x86_64/sha2/.tmp_sha512_impl.o: warning: objtool: SHA512TransformBlocks()+0x1c: unsupported stack pointer realignment

unsupported stack pointer realignment sounds slightly dangerous. But again, I can't judge.

Describe how to reproduce the problem

1. Install debian buster from the official repositories, using linux-image 4.19.0-12-amd64. Install linux-headers-4.19.0-12-amd64 and the usual build tools.

2. Download and unpack https://github.com/openzfs/zfs/releases/download/zfs-2.0.0/zfs-2.0.0.tar.gz somewhere (e.g. /install).

3. cd into the download / unpack directory and follow the instructions on the ZFS build HowTo (https://openzfs.github.io/openzfs-docs/Developer%20Resources/Building%20ZFS.html) to get the prerequisites and to build the software, with one exception: Do not clone the GitHub repository, but use the sources from the tarball you have downloaded and unpacked in step 1). Wherever the HowTo shows different steps for different distributions, follow the steps for the debian / ubuntu variant.

4. One of the steps the HowTo mentions is make -s -j .... While make runs, observe the warnings mentioned above in its output.

Include any warning/errors/backtraces from the system logs

The warnings have been shown on stderr, and I have shown them in the problem description. We did not check the logs because that wouldn't reveal additional information.

[behlendorf]

I'm glad to hear you didn't run in any significant issue when building for Buster. Regarding the two specific warning you did encounter:

ar: u' modifier ignored since D' is the default (see U')`

This is something I noticed as well when building on Debian and Ubuntu. To my knowledge it's never caused any problems and can be safely ignored. Though I'd love to see it investigated and resolved in case it might someday turn in to an issue.

warning: objtool

As for the objtool warnings they are also benign and there's some analysis in #6950. Again we'd like to resolve them, but so far it hasn't been a priority.

[Binarus]

@behlendorf Brian, thanks for the explanation.

I already suspected that these were just warnings, and I can confirm that OpenZFS runs without issues (except the performance issue I have described elsewhere) on one of our servers (and soon it will be two). However, I guess we don't use SHA in our setup (unless something happens behind the scenes which is not configurable), which the last three warnings I mentioned relate to.

We are still investigating the performance issue. When we have solved or have given up on it, we probably will try to have a closer look to those warnings.

Thanks again!

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[behlendorf]

The objtool warnings have been resolved by 7c9702e. However, the ar: u' modifier ignored since D' is the default (see U') warnings still need to be investigated. Not Stale.

[szubersk]

@Binarus The issue here (which can be very safely ignored) is

Debian buster

$ autoconf --version
autoconf (GNU Autoconf) 2.69
$ grep -wr cru .
...
config/libtool.m4:: ${AR_FLAGS=cru}
...

Debian bookworm

$ autoconf --version             
autoconf (GNU Autoconf) 2.71
$ grep -wr cr .
...
./config/libtool.m4:: ${AR_FLAGS=cr}
...

ar(1) says

       D   Operate in deterministic mode.  When adding files and the archive index use zero for UIDs, GIDs, timestamps, and use consistent file modes for all files.  When this option is
           used, if ar is used with identical options and identical input files, multiple runs will create identical output files regardless of the input files' owners, groups, file
           modes, or modification times.

           If binutils was configured with --enable-deterministic-archives, then this mode is on by default.  It can be disabled with the U modifier, below.
...
       u   Normally, ar r... inserts all files listed into the archive.  If you would like to insert only those of the files you list that are newer than existing members of the same
           names, use this modifier.  The u modifier is allowed only for the operation r (replace).  In particular, the combination qu is not allowed, since checking the timestamps
           would lose any speed advantage from the operation q.

       U   Do not operate in deterministic mode.  This is the inverse of the D modifier, above: added files and the archive index will get their actual UID, GID, timestamp, and file
           mode values.

@behlendorf I think we could close this ticket as it depends purely on autoconf version.

[behlendorf]

I think we could close this ticket as depends purely on autoconf version.

Agreed. For future reference, here's the upstream autotools thread discussing the issue along with the patch.

https://www.mail-archive.com/[email protected]/msg04283.html