More technical version of the same discussion here: https://lore.kernel.org/lkml/CAB9dFdsZb-sZixeOzrt8F50h1pnUK2...
Linus: Don't Use ZFS
181–190 of 571 posts
Re: Linus: Don't Use ZFS
#182Here's his reasoning: "honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd. Other people think it can be ok to merge ZFS code into the kernel and that the module interface makes it ok, and that's their decision. But…
> And I'm not at all interested in some "ZFS shim layer" thing either If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address. Expecting all Linux drivers to be GPL-licensed is unrealistic and just leads to crappy user experiences. nVidia is never going to release full-featured GPL'd drivers, and even corpor…
There is an "approved" method - write an publish your own kernel module. However if your module is not GPL licensed it cannot be published in the linux kernel itself, and you must keep up with the maintenance of the code. This is a relatively fair requirement imo.
Re: Linus: Don't Use ZFS
#183As a heavy user of ZFS and Linux, what else is there that even comes close to what ZFS offers? I want cheap and reliable snapshots, export & import of file systems like ZFS datasets, simple compression, caching facilities(like SLOG and ARC) and decent performance.
Bcachefs is probably the only thing that will get there. The codebase is clean and we'll mantained, built from solid technology (bcache) and will include most of the ZFS niceties. I just wish more companies would sponsor de project and stop wasting money on BTRFS
Which is why ZFS is still a thing today - there are no other alternatives. Everything is coming "soon" while ZFS is actually here and clocking up a stability track-record.
Re: Linus: Don't Use ZFS
#184Honestly, at this point if I can't get ZFS in Linux I would move to FreeBSD whenever I need big filesystem. How does Linux® Binary Compatibility layer work on FreeBSD?
It implements the x86 and x86_64 Linux system call ABI. Linux ELF binaries get vectored to an alternate system call table implemented by the compatibility layer. There are some other components like an implementation of a Linux-compatible procfs. How well it works in practice really depends on how far off the beaten path you go. There are lots of non-essential pieces that are not implemented, but for example I know of people running Steam on FreeBSD.
Re: Linus: Don't Use ZFS
#185Earlier quoted context omitted.
Take a cursory look into both codebases, the stability of the every feature at launch and on maintenance. It's not hard to see BTRFS is a doomed project. Bcachefs is more like PostgreSQL, the developer doesn't add features until he has a solid design that's well thought out. Hence why he hasn't implemented snapshots. I don't think too many people consider it stable enough for production, either. (Unless you count a v…
If you are on BTRFS and you encounter an unrecoverable bug (which seems to be reasonably common), the developers will most likely recommend you wipe the drive and restore from backups (because you had backups, right?) Even if the data is still on the drive and a bugfix would make the filesystem recoverable again, they don't have the time/knowledge/resources to untangle that codebase and make fixes. Even BTRFS develop…
Just want to note that bcachefs looks great (I was sort of tangentially aware but hadn't dedicated significant attention to it).
Definitely something to try out (backing up my home servers is just about to reach viability for me, so I'd definitely consider switching to it in that use case).
Thanks!
Re: Linus: Don't Use ZFS
#186Earlier quoted context omitted.
Relevant bits: "Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me. The benchmarks I've seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place?"
> The benchmarks I've seen do not make ZFS look all that great. The thing about ZFS that actually appeals to me is how much error-checking it does. Checksums/hashes are kept of both data and metadata, and those checksums are regularly checked to detect and fix corruption. As far as I know it (and filesystems with similar architectures) are the only ones that can actually protect against bit rot. https://github.com/zf…
> those checksums are regularly checked to detect and fix corruption.
I don't believe that's true. They are checked on access, but if left alone, nothing will verify them. From what I've read, you need to setup a cron job that runs scrubbing on some regular schedule.
Re: Linus: Don't Use ZFS
#187Earlier quoted context omitted.
I've tried btrfs without much luck. btrfs still has a write hole for RAID5/6 (the kind I primarily use) [0] and has since at least 2012. For a filesystem to have a bug leading to dataloss unpatched for over 8 years is just plain unacceptable. I've also had issues even without RAID, particularly after power outages. Not minor issues but "your filesystem is gone now, sorry" issues. [0]: https://btrfs.wiki.kernel.org/in…
It's not a bug, but an unimplemented feature. They never made any promise that raid5 is production-ready. Pretty much all software-raid systems suffer from it unless they explicitly patch over it via journaling. Hardware raid gets away with it if it has battery backups, if they don't they suffer from exactly the same problem.
... hence the desire to use ZFS, which skips trying to present a single coherent block device and performs parity at the file (chunk) level.
Re: Linus: Don't Use ZFS
#188Alright, Linus, I'll make you a deal: I'll consider dropping ZFS when you ship a production-grade BTRFS (or reiserfs or anything else with the same features).
Is reiserfs still maintained. After Hans went to prison I didn't think there was much left beyond stagnation.
Re: Linus: Don't Use ZFS
#189Earlier quoted context omitted.
> people probably will, in a few years. Yes, but without the array as you stated. We have 300+ 10TB disks at our datacenter today and, ZFS is relevant at this disk count, I/O and client load. Running ZFS at small scale is raising a cow at home for a bucket of raw milk. It's more of a fun curiosity rather than a production level operation. I'd run LVM or md or something similar at home instead of a full blown ZFS setu…
I feel ZFS are much better and easier than md or LVM. At least had it been properly supported (I have never tried ZoL). CoW and cheap snapshots are game-changers, checksums as well but maybe not from a practicality and home-user standpoint. This holds just as well on PB storage as a 512 GB OS drive as a 2 GB thumb-drive (not that I would use ZFS on a thumb drive - again because of proper support across different OS).
Checksums are amazing for when you do have a problem, because a scrub will tell you what you lost. Knowing what's been damaged is practically more important then actually fixing it, and ZFS is great at this.
All the Linux alternatives answers to this problem are always "is your data okay? Don't know! It'll be a surprise when you get there".
Re: Linus: Don't Use ZFS
#190Earlier quoted context omitted.
Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…
> - Performance is not that great compared to the alternatives. CoW filesystems do trade performance for data safety. Or did you mean there are other _stable/production_ CoW filesystems with better performance? If so, please do point them out!
XFS on LVM thin pool LV. Stable and performant as far as I can tell.