[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ZFS in Buster



On 28.05.19 18:43, Dan wrote:

> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0> that prevents ZFS from using SIMD. The result is that ZFS won't be>
usable in Buster. See the following issue>
https://github.com/zfsonlinux/zfs/issues/8793
We recently had this discussion on lkml - yet another case of 3rdparty
folks that just don't follow the license rules.

It's not the kernel who broke zfs, it's zfs that broke itself. The
kernel is GPL, and they just have to follow the rules or go away.

OOT modules are conceptionally messy in the first place. It's sometimes
okay as an temporary workaround, until things get mainlined. But
intentionally keeping things oot for long time is just silly and creates
lots of more problems than it creates.

And they're even using now *deeply* arch-internal functions directly.

> NixOS reverted that particular commit:>
https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop
Intentional license violation. Not funny.

> Debian is the "Universal Operating System" and gives the user the> option to choose. It provides "vim and emacs", "Gnome and KDE",
If you wanna have something new included, you'll have to sit down and do
the actual work. In the end of the day, it's that simple.

> Would it be possible to provide an alternative patched linux kernel
> that works with ZFS?

You mean patching against the license ?

> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

Wait, no. It's not that we refused anything (actually, I don't even
recall any decent discussion on that @lkml). There even wasn't anything
to accept or refuse - except the existing code, that is nowhere near
a quality where any maintainer likes to even have a closer look at.

The major problem is that ZoL always has been oot on purpose, which is
the wrong approach to begin with. That also leads to bad code quality
(eg. lots of useless wrappers, horrible maintenance, ...)

What ZoL folks could do is step by step rewrite it to use mainline
functionality where ever technically feasible and work closely with
upstream to introduce missing functionality. Obviously, their current
proprietary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)

But it's up to ZoL developers to do the actual work and post patches
to lkml. There won't be anybody else doing that.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287


Reply to: