Hacker News new | ask | show | jobs
by nickik 2341 days ago
Being 'The Dude' of file system is literally the opposite of what I want. When looking at ZFS talks and the incredible complexity of some of those operations that Btrfs seems to think are 'no big deal', I will simply not trust that. Specially because it has been proven over and over again that Btrfs claims its 'stable' and then a new series of issues show up. Or its 'stable' but not if you use 'XY feature', or if the disk is 'to full' or whatever.

I remember using it after I had heard it was 'stable' and it eat my data not long after (not using crazy features or anything). I certainty will not use it again. A FS should be stable from the beginning, as stable core that you can then build features around, rather then a system with lots of feature that promises to be stable in a couple years (and then wasn't years after being in the kernel already).

Using ZFS for me has been nothing but joy in comparison. Growing the ZFS pool for me has been no issue at all, I never saw a reason why I would want to reconfigure my pool. I went from 4TB to 16TB+ so far in multiple iterations.

Overall not having ZFS in Linux is a huge failure of the Linux world. I think its much more NIMBY then a license issue.

2 comments

> I think its much more NIMBY then a license issue

How do you propose that ZFS be brought into Linux? When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel. This was no accident. At the time, Sun was still pushing OpenSolaris which was losing ground to Linux. The ZFS on Linux project gets around this restriction by running ZFS in user space, but this is not optimal.

You can make a legitimate argument that Linux should have been released under a BSD style license (I think that would be wrong, but it's plausible). I don't see how you can argue that ZFS's license is somehow the fault of the Linux world.

> The ZFS on Linux project gets around this restriction by running ZFS in user space

ZFS on Linux is a kernel module. You may be thinking of ZFS-FUSE which runs in user space using FUSE, but I'm not sure if it's being maintained any more.

On the other hand, choosing to use GPL would prevent it from being integrated anywhere else. You'd also lose the patent protection granted by CDDL.
It's not like they couldn't use dual licenses, like Mozilla did at the time, for example.
Any license more liberal than the GPL would also be fine. For example: MIT/X11, 2-clause BSD, or Ruby's license.
> When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel

This is simply totally false no matter how many times people repeat it. It pure FUD.

Sun picked the licence because they had to allow linking with closed code for their products, going with the GPL was simply not viable given the situation with drivers on their platforms. Their licence is actually build on the Mozilla licence without forcing resolution in California. Sun actually spend quite a bit of time and resources to develop a really good licence and made it as open they could given their constraints.

Also, Sun very agressivily pushed their technologies to other systems and Linux would have been no exeption. Sun helped Apple integrate D-Trace, and at the same time the hedge an evil plan to not give it to Linux? They helped upstream things to the BSDs as well.

That simply conspiricy nonsense that was typical with the 'its actually GNU/Linux' crowd that was pushed in the 2000s. Sun was seen as evil coorprate trying to stamp on the 'real open source' community, looking back on this now, the absurdity of that sentement should be clear. Sun made mistakes, but their overall track record was staller.

The idea that the function of the GPL is to block other Open Source code from integrating into an Open Source project is an abolute insane concept and a total perversion of the Idea of Open Source. Literally using the supposed 'most free' GPL to activly block and exclude other Open Source code from people.

Sun's motivation for choosing the CDDL is beside the point. Unless ZFS is released under a license that allows it to be redistributed under the GPL, ZFS cannot be legally built into Linux as a filesystem.

If you have reason to believe that Linux developers can go ahead and simply integrate ZFS into Linux without worrying about the license, I'm sure lawyers from the FSF, IBM, Cannonical, etc would love to hear your explanation.

Uh, isn't Canonical already shipping ZFS in the latest Ubuntu? https://www.techrepublic.com/article/something-exciting-is-c...

Their argument (as I understand it) is that loadable kernel modules are separate discrete pieces of software that do not become "part of" the kernel and do not have to care about kernel licensing. They can be any license, including proprietary, like nvidia drivers.

There is about zero need for "integration" as in static linking / inclusion in the linux repo btw. Nothing wrong with dkms.

This is not a new thought and the lawyers actually understand this. GPL was not designed to protect user from open source. And its an idiotic missapplication. Oracle themself diliver ZFS with Linux, and so do many, many others.

The only 'argument' is that we can't do it because 'big bad oracle' will sue you but that really doesn't hold up.

> Sun's motivation for choosing the CDDL is beside the point.

GP made a claim to Sun's motivation, rebutting that claim seams reasonable.

> Sun picked the licence because they had to allow linking with closed code for their products

Wasn't Sun always the copyright holder? Licenses only apply to Licensees, not Licensors - or am I missing something (e.g. collaborators not needing to reassign copyright back to sun, etc)..

IIRC, Sun was not the copyright holder of everything in Solaris.
I mostly agree, and that's largely why I use ZFS a lot. But:

> A FS should be stable from the beginning,

If this is your standard, I don't think there's a file system out there that meets it. ZFS has had data-loss bugs. I doubt there is any non-toy file system that hasn't.

I've thought about what standard should apply to this - it is a prove-a-negative problem, that filesystem-X in combination with whatever recent kernel will not lose data. I don't have a good answer, but the one I came up with is "multiple years without a dataloss bug, of quick turnaround to other bug fixes, and a warm-fuzzy feeling about the developers."

It was designed to primary not lose data from the very beginning. That was at the very core of every design choice. Maybe there were a few such bugs but I have not read of any, while in comparison Btrfs I have read a whole of them.

Compare how bcachefs/zfs approaches these challenges and then go back to the early years of Btrfs. There is really no comparison.

I don't disagree that maintainer-goals and practices make me trust ZFS more. They do. But there have been bugs. Last major one I remember in the core code is this one:

https://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss...

But there was a Linux-specific data loss bug with ZFS in 2018:

https://github.com/zfsonlinux/zfs/issues/7401

Of course you should use what you like. And I agree that ZFS is safer. But again, I don't know of any file system that can say it has "been stable from the beginning", if stable means no data loss.