Comment by morning_gelato | Hacker News Reader

Comment by morning_gelato | Hacker News Reader

Parent Full thread

I'm not sure what you mean by ZFS being such a big problem, the CDDL license is considered incompatible and therefore OpenZFS isn't going to be considered for upstreaming. Also, most of OpenZFS development is driven by companies that use it with the Linux kernel, so clearly there isn't that much of a problem with using OpenZFS and Linux. It's pretty similar to how the BSDs may not allow something in base due to licensing, but will allow it in ports/pkg.

If you're asking why OpenZFS is not hosted kernel.org, why would kernel.org host an out of tree kernel module that is never going to be upstreamed? Firmware on the other hand is needed to initialize and use a ton of hardware, and so it makes sense to have a central repository for vendors to submit required firmware. More importantly, why would the OpenZFS community even want to be on kernel.org when they support multiple operating systems and have also not pushed for upstreaming? I really don't think OpenZFS is being treated any better or worse than other license-incompatible kernel modules.

I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base [1], or OpenBSD sticking with Clang 8 in base because of the switch to the Apache 2.0 license [2]. It's pretty normal for software projects to care about licensing.

[1] https://wiki.freebsd.org/GPLinBase

[2] https://lists.llvm.org/pipermail/llvm-dev/2017-April/112300....

Of course ZFS can't be upstreamed (anymore than assorted blobs), but Linux devs have expressed outright animosity towards ZFS: https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-L...

> My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?

Sure, but that's been Greg KH's stance on pretty much every kernel module that has no chance of going upstream [1].

"Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech)."

Also in the post you are citing, the technical change makes no reference to ZFS [2] or implies that the motivation is to break out of tree modules. The upstream community simply doesn't even consider out of tree projects when making changes. Whether that's good or bad is another discussion, but I don't see anything that's specific to ZFS.

I should also note that to my knowledge, OpenZFS (formerly ZoL) was the only (open source) ZFS implementation that utilized vectorized checksums. At the very least FreeBSD's in-tree ZFS did not have vectorized checksums, as that was listed as one of the features FreeBSD would gain by moving to OpenZFS [3]. So the cited change didn't break ZFS, it just meant those checksums weren't as fast as they used to be.

[1] https://www.kernel.org/doc/Documentation/process/stable-api-...

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[3] https://lists.freebsd.org/pipermail/freebsd-current/2018-Dec...

>good luck, you are on your own here, you leech

Man i just love that warm, lovely atmosphere in that project..and thats not even the leader....ahem sorry dictator (and he is even proud of that)

Linux just loves good filesystems (not).

The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.

Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied. Of course, the only filesystems they can make are all crap like ext4 and btrfs.

Fortunately, there's the BSDs, and there's the likes of HAMMER2 from Dragonfly.

And, with seL4[0], Fuchsia and HarmonyOS making progress, Linux is going to fall into irrelevance, sooner than most think.

Good riddance.

[0]: https://sel4.systems/About/seL4-whitepaper.pdf

> The way they are handling ZFS reminds me of the way they handled Reiser4, Tux3 and Reiserfs.

The latter file systems were trying to be upstreamed and ultimately did not succeed, I don't know of any interest or attempts at upstreaming ZFS. Their handling of ZFS reminds me how they handle any kernel module that will never be upstream, not because some file system establishment sees it as a threat.

> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.

What/who is the "establishment (and their friends)"?

f2fs from Samsung was added in 3.8, erofs from Huawei was added in 5.4, and exfat from Samsung was added in 5.7. Before those file systems were upstreamed I don't think many people would list Samsung and Huawei as part of the filesystem "establishment".

>What/who is the "establishment (and their friends)"?

Maybe he thinks of Linux Foundation Platinum Members ;)

https://www.linuxfoundation.org/membership/members/

XFS is actually really good, but Linux definitely need's a check-summing COW Filesystem that's usable.

FWIW, we do have CoW on XFS, but yeah no data-checksumming other than BTRFS. Hopefully bcachefs will be the go-to option someday.

Yes true and check-summing for metadata too, but not for the data. I have bigger hopes for XFS then bcachefs (maturity and really great dev's) but hopefully not that Stratis-thing from redhat....that sound's like a terrible idea.

Writeback latency spikes and lack of data checksums is the main issue with ext4 and xfs.

Btrfs has the checksums, but is a toy.

To my knowledge, NILFS2 (by NTT) is still the best filesystem Linux has in mainline. And, ironically, practically nobody does use it.

Does NILFS2 ensure data integrity? [0] claims that it doesn't actually check data checksums, but that's from 2011...

[0] https://www.spinics.net/lists/linux-nilfs/msg01063.html

Yes it does:

https://en.wikipedia.org/wiki/NILFS#Additional_features

> the way they handled Reiser4, Tux3 and Reiserfs

Reiserfs is in-tree. Reiser4 failed after losing its lead dev, but my impression was that it was on-track to become the next Linux filesystem of choice. I have no clue about Tux3.

> Basically, any filesystem not made by the filesystem establishment (and their friends) gets bullied.

Linux has XFS from IRIX and JFS from AIX; the only way to have that and a "filesystem establishment" conspiracy is to resort to no-true-scotsman.

> Of course, the only filesystems they can make are all crap like ext4 and btrfs.

I'll agree that BTRFS is ... suboptimal, but what do you have against ext4? I'd like it to have data checksums and maybe CoW, but it's been the workhorse of the Linux world for ages and performs quite well, and even has some nice new features like encryption in recent times.

>Reiserfs is in-tree.

Yes it is, but it got bullied either way. Linux filesystem devs made incompatible changes to it against the ReiserFS teams' wishes, breaking it. IIRC it had to do with ACL support.

>CDDL license is considered incompatible

Well NO its not, that's pure FUD from the FSF:

https://zonena.me/2019/01/the-cddl-is-not-incompatible-with-...

>If you're asking why OpenZFS is not hosted kernel.org

No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.

>I just don't see how you can characterize it as zealtory any more so than FreeBSD wanting to remove all GPL'd software from base

That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD (or compatible like Apache/MIT etc) License.

> Well NO its not, that's pure FUD from the FSF:

What matters is if the upstream Linux community is comfortable enough with the license to allow it upstream, which is why I said "considered".

> No im asking why Linus thinks its acceptable to distribute proprietary Firmware, but needs a personal letter from Lord Elison and ZFS needs to be GPL'd....otherwise just don't use it.

There's a big difference between these two things. The first is redistributing proprietary firmware in a completely separate repository from the Linux source code. All firmware included in the linux-firmware repository is explicitly allowed to be redistributed [1], which is why they do not have fears about distributing those binary files.

I'll quote the readme: "If your commit adds new firmware, it must update the WHENCE file to clearly state the license under which the firmware is available, and that it is redistributable."

The second is introducing CDDL licensed code into a GPLv2 project, where that project considers the CDDL license to be incompatible, along with worries (however unfounded) about a notoriously litigious company.

> That is because you can close and still distribute BSD licensed Software, but not when it contains GPL'd Software, thats why you dont want it in the Base-System, no one has something against GPL there, but FreeBSD wants to distribute a complete Operating-system under the BSD License.

Yes the FreeBSD community does not want GPL code in the base system as it prevents them from from distributing a 100% permissively licensed system, and it's understandable why that is a goal. But how is that meaningfully different than the Linux community not wanting code with a license they feel is incompatible with their goals?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Again NO one wants ZFS being in the mainline kernel, but being openly hostile against it, but accept closed Firmware (because they have to...who is the leech now?) is not completely honest.

I've already said that the OpenZFS community is not trying to upstream it, why do you keep thinking that I'm suggesting otherwise?

You continue to conflate support for out of tree kernel modules as being similar to having a separate repository for firmware when they aren't the same thing at all. The Linux developers are not accepting firmware into the kernel at all, so there is no contradiction. The firmware is kept separate, just like OpenZFS is kept as a separate project from Linux. In both instances the user can choose to install an out of tree module such as OpenZFS as well as choose to install firmware on their system.

Furthermore it is not the Linux kernel developers that are packaging and shipping the firmware, it is the various Linux distributions who do that (or not in the case of FSF-approved distributions).

Reply on news.ycombinator.com