Hacker News new | past | comments | ask | show | jobs | submit login
Linus Torvalds says “Don’t use ZFS”–but doesn’t seem to understand it (arstechnica.com)
40 points by Analemma_ 8 days ago | hide | past | web | favorite | 15 comments





Some miscommunication here. TFA doesn't distinguish between Oracle's ZFS and the Solaris fork, OpenZFS. Linus seems to be making comments about the former and is likely mixing up a few details about ZFSonLinux. His non-maintenance comments also appear to be about about the fork and probably mean "not keeping pace of feature parity with ZFS proper", which it doesn't.

I think he's just baffled by why anyone would expect the Linux kernel to make a special exception to support ZoL when there are already great native tools and the BSDs exist. And if you really need production ZFS, why not just buy into the officially maintained version from Oracle because you're not getting on-call support, paid or otherwise, from the open projects or Linux.

Largely, the article contains no impact or petition and reads like a click-trap set with Linus bait by someone with a real interest in defending (Open)ZFS's cult status as the pinnacle of all filesystems. I use ZoL at home, but it's not something I'd expect to see above SMB.


> I think he's just baffled by why anyone would expect the Linux kernel to make a special exception to support ZoL when there are already great native tools and the BSDs exist. And if you really need production ZFS.

Couple things, first, some race conditions have been fixed on ZoL but not on the BSDs openZFS. It has been decided that ZoL is the "reference now.

Second, sometimes we may just want to switch from ext4 to ZoL but don't have the luxury to switch OSes.


> already great native tools

This really is not the case. The closest thing is btrfs, which has a more limited feature set and a justified reputation for eating data; it's impossible to do a safe equivalent of e.g. a raidz2 pool with it


> I think he's just baffled by why anyone would expect the Linux kernel to make a special exception to support ZoL

This isn't about special exceptions for ZoL. It's about removing FPU access in what appears to be a swipe by Kroah-Hartman against ZFS (maybe it was coincidental - we'll never know).

> And if you really need production ZFS, why not just buy into the officially maintained version from Oracle because you're not getting on-call support, paid or otherwise, from the open projects or Linux.

In that case, why use open source at all? Because you're not getting on-call support, paid or otherwise. And yet almost all modern companies DO use open source products in production.

> Largely, the article contains no impact or petition and reads like a click-trap set with Linus bait by someone with a real interest in defending (Open)ZFS's cult status as the pinnacle of all filesystems.

Really? So the part where he says that his gripe is about the public, well-respected figure Linus, publicly denigrating and spreading misinformation about another open source project while remaining willfully ignorant about it, contains no impact or petition?

If Microsoft had done it, we'd all be crying FUD.


> It's about removing FPU access in what appears to be a swipe by Kroah-Hartman against ZFS (maybe it was coincidental - we'll never know).

It wasn't Greg Kroah-Hartman: https://git.kernel.org/torvalds/c/12209993e98c5fa1855c467f22...

That commit has the real reason: "With EFI gone as the last user of __kernel_fpu_{begin|end}(), both can be made static and not exported anymore." So yes, it was fully coincidental.


I already said it in another thread, but IMO Linus's comments are best seen as a legal positioning to avoid Oracle's thugs going after him for copying ZFS features or for developing code that he knows will be mingled with CDDL.

Having said that, I don't understand why ZoL can't just declare itself as GPL to the kernel and get access to whatever symbols it wants. I thought the only legal teeth that mechanism had is for showing willfull infringement. But ZoL releases source and already bridges the GPL and CDDL by strictly delaying their mixture until runtime, so I would think additional GPL objections by the kernel would be moot.


> Linus should avoid authoritative statements about projects he's unfamiliar with.

I'd side with the author here since he's shown to have experience and researched his points with using ZFS here and is quite frankly clear around explaining the background of ZFS enough to disqualify Linus's arguments for telling those who agree with him "Don't use ZFS".

I may have not gone as far as the author to do the benchmarks themselves, but the most misunderstood claim that Linus clearly went off the rails on what the claim about ZFS being unmaintained. As a part time Linux/BSD user, using Linus's own ranting language: This is complete B___S___.

When talking about "The" Linux kernel (no distros), Linus has his merits and his most excellent and decorated highness is respected by software engineers worldwide for the kernel. But as soon as he gets involved with topics which he has done little research and a clear lack of understanding, then the real experts will notice.


Isn't this completely irrelevant to the discussion?

Linus's only point was that ZFS for Oracle reasons can't be included in the kernel (despite what Canonical thinks). ZFS may have some nice features but is not worth the headache to rely on a possible copyright infringing, out-of-tree model backed by Oracle.

I have thus far seen nobody who disagrees with this. Instead people seem to got hung upon nitpicking or their own ego. E.g. but the features are important to me and not buzzwords. Good for you, every non-BSD OS thus far lived without them. Or "unmaintained". Of course it has maintainers, but *BSD switch to basing itself on ZFS on Linux because they don't have enough.

TLDR: Hyperbole != wrong and nobody disagrees with the substance just with the tone.


This is not correct. The api that was disabled was deprecated for over a decade when disabled. It was an api that wasn't meant to be used. Zol folks kept using it out of tree and when Linus finally removed/hidden them people went apeshit thinking it was some sort of attack. It wasnt, it was 12 years late...

Quoting Linus himself (https://www.realworldtech.com/forum/?threadid=189711&curpost...):

> We didn't go out of our way to deliberately break anything.

> But we do occasionally turn symbols that aren't meant to be used outside the kernel into GPL-only, because they have some internal implementation issues.


An api may not be meant to be used but what makes it important to hide it? They could just let it be until there is a real need to delete it. Just going out of your way to hide something is a bit hard to understand.

It is the next step leading up to deleting it.

There are very good reasons to delete unmaintained or hard-to-maintain code that nothing important depends on, or should depend on. But just deleting it creates hardships, so things happen in stages.


His point is a bit deflective of the issue. They intentionally disabled api to my understanding for non GPL modules that zfs on linux relied on. No one asked for ZFS to be integrated in linux. I hope someone with better understanding than me can confirm or infirm.

I agree with the author... The last few paras really explain what was supposed to be conveyed:

- If you don't want to use it, don't want to muck around with the license, fine ...

- But don't dis a FS that has been solving important problems for a few YEARS in production even before btrfs was being written.

Perfect summarization there. As a tech person, we could get biased into dissing other people's tech. But I feel that where it's due, one needs to give credit.

Historic aside: ZFS is 14+ years old, launched in November 2005. It's sort of a feature-parallel version of WAFL but eventually open sourced to the world with OpenSolaris in 2008. I used to work in NetApp when it came out and I was like, whoa. NetApp and Sun share a lot of history.


Has ZoL integrated with the page cache yet so I don't have two dueling caches?



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: