daemon/graphdriver/btrfs/btrfs.go args.lim.max_referenced undefined

[s4uliu5]

Description

While building docker-20.10.22 on Funtoo linux with btrfs-progs 6.1, got this error

daemon/graphdriver/btrfs/btrfs.go:437:11: args.lim.max_referenced undefined (type _Ctype_struct_btrfs_qgroup_limit has no field or method max_referenced)

Reproduce

1. extract source
2. hack/make.sh dynbinary

Expected behavior

Build not fail.

docker version

Not relevant.

docker info

Not relevant.

Additional Info

Only fails with btrfs-progs 6.1, with previous versions (6.0.x) builds ok.

IMHO the change of btrfs-progs that caused this affect is

kdave/btrfs-progs@0345143

[thaJeztah]

Thanks for reporting! Hm... from that commit (kdave/btrfs-progs@0345143);

ioctl.h is a public header but there are no users of the btrfs_qgroup_limit structure.

Looks like they missed that it was used in this repository (at least; it's possible other runtimes may be using it as well). I see use of it was added for quota support in 401c8d1 (#19651)

That will be a tricky one; I don't think we can easily change the code to match the new version (as we need to build for various distros, most of which will still have the older btrfs-progs).

@kdave @josefbacik any suggestions how to keep it backward compatible?

[Conan-Kudo]

@thaJeztah This change will be reverted in the next btrfs-progs bugfix release (v6.1.1): https://lore.kernel.org/linux-btrfs/20230103113941.GN11562@twin.jikos.cz/

[Conan-Kudo]

FYI, the (correct) longer-term fix is to move to libbtrfsutil instead of using libbtrfs: https://lore.kernel.org/linux-btrfs/20230103120640.GO11562@twin.jikos.cz/

[thaJeztah]

Thanks for the heads-up @Conan-Kudo - appreciated! ❤️

We had some discussion about what headers would be best to use, and why we were not using the kernel headers (that last part we tracked down to support for RHEL7, which had experimental support for BTRFS, but (I think) not in the kernel headers of the kernel version used - @corhere or @neersighted did some digging into options).

[neersighted]

Indeed, the plan is to depend on the kernel uAPI here, which exposes the fields we currently use. That being said, libbtrfsutil is good to keep in mind if we need to depend on functionality not in the uAPI in the future (e.g. userspace code).

[Conan-Kudo]

using the kernel uAPI directly tends to be problematic since the btrfs-progs keeps a copy of the latest interfaces with backwards compatibility for older kernels, whereas the uAPI headers in the kernel lack this.

[neersighted]

That's true -- however the only kernel without the fields we currently need is EL 7's 3.10-based kernel. In the case of a EL 7 system, newer kernel headers can be used, or one can simply not compile the Btrfs graphdriver (which should be preferred as all EL 7 vendors shipping a Red Hat-compatible kernel have deprecated support; OL 7 users on the UEK will have the correct uAPI headers available).

If this situation changes and header availability is more of a concern, we'll likely depend on the userspace versions again.