ZFS + Kernel 5.0 onwards - ZFS hobbled?

Be aware of this if you currently use ZFS or are considering it. As of Kernel 5.0 it's not going to be given the time of day by the kernel maintainers. It's to do with Oracle not releasing ZFS to GPL. ZoL developers are trying to sort a workaround to keep their forked ZFS working with kernel 5.0. How it actually performs with the new kernel as a result of these changes is another matter. Details of the 'fix' and what the restrictions are can be found on Phoronix or the GitHub link for zfs below:

I may be misinterpreting this but it seems a lot like ZFS is dead in the water from this point forwards now unless you stick to LTS kernels with proper ZFS support or run BSD instead of Linux.


At this point it isn't even clear what/where the performance impact will be. Additionally, the developers are still squabbling. They have to make these changes to at least get it compiling again with the Linux 5.

zfs has fairly substantial use in enterprise server environments and there is no similar alternative for enterprise purposes yet. It doesn't seem likely that it will disappear in the near-term.

in fact Oracle has not enough worked on lock and concurency in ZFS ,
or IXsystem has made many reports , and no really soluce come from Oracle for FreeBSD

that's what they go to Zol ....

Yes, you are misinterpreting this.

ZFS uses this kernel function to calculate vectorized checksums on x86 architectures where that function is available. On all other architectures it is not using that function anyways.


I seem to remember a quote from Linus along the lines of "If a kernel change breaks userspace it's a bug in the kernel".

Now a kernel change broke userspace and... it's a userspace issue.


If it is a bug then it seems to be a definite case of won't fix as far as Greg K-H is concerned.

This does make me wonder who is really in charge of Linux Kernel these days though since Greg "my tolerance for ZFS is pretty non-existent" appears to be calling the shots at the moment.

ZFS could be the best file system ever to grace this planet, that's fantastic, but given that the creators of that code placed it under a license that was specifically designed to not be compatible with Linux to prevent it from ever being used on Linux, well, you can see why I really don't care about it. Why would I?

@mbod The blocking of hardware accelerated file checksum processing will impact on file system performance though, it just depends how much of an effect it really has in general usage. it may be so minimal that all this arguing among the developers is just another pissing contest that should be ignored by the rest of us.

What I'm wondering though is what else will fall foul of the kernel policy changes regarding GPL compliance?

Did they make kernel policy changes? I thought they just removed some exports that weren't being used internally by the kernel anymore.

It is certainly a strategic decision that has consequences, also why now in particular? Does it really hurt (excess code or maintenance) to leave the exports in? Maybe I asked the wrong question then.

The GPL issue is probably separate but it comes across as being the reason behind the lack of giving a damn about ZFS

I know they won't add the exports back just because it broke something in ZFS, but maybe if the impact is wider spread to other external projects reliant on the exports the decision will be revisited?

ZFS isn't userspace, it's out-of-tree kernel module. Neither Linus "Fck you Nvidia" Torvalds or Greg "My tolerance for ZFS is pretty non-existant” K-H ever spoke favourably of support for out-of-tree code in kernel.

That's not nice but it's consistent.


In the german debian forum people are saying that one possible solution is to use ZFS with dkms:


This will eliminate the license issue and will make the deprecated function available again for ZFS.

I found an interesting statement about the deprecated symbols/functions in linux 5.0.

From one of the zfs developers on the zfs user mailing list:

Do you realize that we don’t actually need the symbols that the kernel removed. It All they do is save/restore of register state while turning off/on preemption. Nothing stops us from doing that ourselves. It is possible to implement our own substitutes using code from either Illumos or FreeBSD or even write our own.

Honestly, I am beginning to think that my attempt to compromise with mainline gave the wrong impression. I am simply tired of this behavior by them and felt like reaching out to put an end to it. In a few weeks, we will likely be running on Linux 5.0 as if those symbols had never been removed because we will almost certainly have our own substitutes for them. Having to bloat our code because mainline won’t give us access to trivial functionality is annoying, but it is not the end of the world.

And furthermore:

We do not need the symbols in this situation. It is perfectly possible to write our own replacements. We just did not because there was no point in bloating the codebase by duplicating code.


good to know, thanks for sharing. if they can sort it in-house by the time kernel 5.0 is an actual release then kudos to the zfs maintainers.

A post was split to a new topic: My positive experience with ZFS on Manjaro

Forum kindly sponsored by