[kaylynb]

The Linux kernel devs hate ZFS and actively sabotage it even backporting changes specifically to break ZFS to LTS branches.

It's fine if you use something like Ubuntu where it's officially shipped with the distro. If not, be prepared to apply kernel patches whenever the kernel team takes a snipe at ZFS.

I'm not trying to be political here, just my day-to-day experience working with several Linux machines running large zpools. It's still worth it compared to the alternatives but if I could use FreeBSD I would.

[leni536]

It looks like Linux kernel devs just don't care about ZFS, like they don't care about many out-of-tree kernel patches/modules.

[goatinaboat]

Do you have an example of a commit where they did this? Just curious as to how (no need to explain why, I get it)

[magicalhippo]

See https://github.com/openzfs/zfs/issues/8259 for details.

While they didn't remove it to sabotage ZFS, they don't seem to care about it ruining ZFS performance on Linux.

Of course they have no obligation to make ZFS on Linux users happy, still a bit of a bummer tho.

[_emacsomancer_]

The Void team does a good job with managing ZFS as well (it's in the official repos). The unofficial ZFS on Arch is generally ok as well (though Arch's management of kernels is weird and a bit tricky).

[AsyncAwait]

There's absolutely no evidence for this. On the other hand, there's some evidence that Sun made ZFS licensing explicitly non-compatible with the GPL, so as to not "sabotage" Solaris.

Linux has other efforts going on in this area, including Btrfs and Bcachefs - there's also ZoL, of course.

[kaylynb]

Take a look at any of Greg Kroah-Hartman's comments on patches that screw up ZFS.

One of the biggest ones was removing exports of kernel functions that ZFS used for encrypted datasets: https://marc.info/?l=linux-kernel&m=154689892914091

I'm fine with this sort of stuff in general assuming it doesn't affect LTS, but this specific patch was backported to LTS kernels even though it has nothing to do with security or bugfixes. I had several zpools I had to apply custom kernel patches on the machines for no other reason than because somebody is mad at licensing.

Bcachefs isn't even stable enough to use in production. Btrfs is okay, and I've used it before, but it's also a minefield of killing your data depending on what features you use. If you use all the features you need to make it on par with ZFS you may as well dump your data in the trash.

ZFS 'just works' and none of the features are incomplete or have asterisks attached that compromise data integrity. Yeah it has architectural problems, doesn't do stuff the Linux way, and has a license that makes devs angry. It's also never lost a byte for me in production for almost a decade of use.

I know the Linux devs don't owe me anything and I'm not really angry or anything about this. It's just a fact that it's frustrating to have to deal with political problems just to run a server.

[AsyncAwait]

You're just ignoring what I said above. Nobody is out to screw ZoL, but the kernel community doesn't care enough to maintain compatibility with it.

Why, as a kernel dev, would you care if there's no possibility of it ever being mainlined because of decisions Sun explicitly made to be hostile towards your project?

It's like trying to cozy up to someone who just punched me, not happening.

Bcachefs isn't yet up to parity for sure, but it is stable enough for everyday use and doesn't corrupt you data like Btrfs sometimes does. A stable foundation that gets expanded upon daily.