Should we check the kernel version?

[kakra]

Should bees refuse to run with known bad kernel interactions? And maybe print a warning about known minor problems with some kernels?

[Zygo]

Refuse? No, then bees would never run. I'm pulling patches from v4.16 integration branches (two releases ahead of the current release as of this writing), and if bees refused to run due to any known bug, nobody who wasn't building their own kernels off git.kernel.org would be able to run bees at all.

I'm hesitant to add warnings because there is a lot of room for error.

It would be hard to know if the kernels had been patched based on the uts version strings alone. Old stable kernels get bug fixes sometimes years later, and I've used a v4.1 kernel for some time with a lot of patches backported as far as from v4.6). Even the LTS kernels are a roiling cauldron of random btrfs patches.

The extra testing required to keep the warning versions list accurate (with neither false positives nor negatives) would be a large time sink for me. It might not be a time sink for a contributor with access to a larger pool of test users/machines to collect data from, but I'd have to rely on such a contributor entirely. A distro maintainer could easily maintain a kernel version blacklist and put it in the bees startup scripts--they know what patches are in their kernels, and I have a (mostly) complete list of kernel bugs to look for.

There's diminishing value and increasing cost in maintaining support for older kernels. For kernels between v4.4 and v4.10, bees avoided kernel bugs with a delicate balance between the scan/dedup algorithm and thread behavior that is difficult to preserve without extensive testing feedback (master is probably OK today with -c1 but it would take a few machine-weeks of testing to know).

These days I've already stopped testing on kernels before v4.11 (sadly that includes the LTS v4.9 as it is missing some performance bug fixes that don't meet -stable criteria). I am currently considering whether and when to drop support for kernels prior to v4.14 simply because v4.14 doesn't need the older-kernel workarounds any more. The fact that v4.14 also introduces LOGICAL_INO_V2 makes it even more attractive as a minimum kernel version.

I guess another thing I'm considering is adopting Linux kernel version numbers for bees as btrfs-tools does. That way I could say something like "if you're using kernel v4.7, use bees v4.7" and not have to worry as much about breaking older kernel versions in newer bees versions. (The obvious plan with this problem is that it hasn't really worked that way for btrfs-tools either).

[kakra]

Okay, so I'd put a warning into the Gentoo ebuild script to either use the latest kernel or carefully read the README about known bugs.

But my request was more about grave bugs, like the README says "don't try to use with kernel older than 4.xy - it won't end well".

[Zygo]

Before v4.2 there are missing ioctls or the ioctls have restrictions that have since been removed. Bees will fail to do anything useful at all on kernels before v3.16, but it should be mostly inert. Bees will operate inefficiently (it won't be able to handle the last extent of files with non-4K-aligned EOF) until v4.2.

Data corruption and hangs happen from v4.2 to v4.11, except for backported fixes to v4.4 and v4.9. Some of these are related to dedup ioctls, but others are general btrfs problems (i.e. you should not run btrfs on these kernels with some combinations of features, e.g. compression and inline extents).

v4.11 to v4.13 have a crippling performance issue--a risk of temporary kernel CPU lockups for 20 minutes at a time every few days or weeks. Earlier kernels had this too but it was even worse.

v4.14 has thousands of WARN_ON(ref->count < 0) stack traces per day. The fix for those won't land in Linux until at least v4.16, so v4.15 will have the same problem.

Which kernel should be the cutoff? I'd say I'm still waiting for that kernel to appear.

[kakra]

Okay, understood. That makes sense.

[Zygo]

4.14.29 has all but one known bug fixed. The last bug is data corruption on compressed data read near a hole (a new one, different from a similar bug that I fixed last year). bees can trigger it because bees punches a lot of holes, especially in MS Windows disk image dumps.

There are still crippling performance problems with many reflinks to the same extent even in recent kernels; however, the workarounds currently in place in bees seem to mitigate the problem adequately.

[kakra]

Okay, let me see that I can add additional info to the Gentoo ebuild soon.