When the file system performance is important, XFS and EXT4 are the fastest. When the extra features provided by ZFS are important, it becomes the appropriate choice. For BTRFS, I am not aware of any application for which it would be the right choice.
But for the second one: when a file is striped across different physical disks with possibly different characteristics, how would you defrag it without knowing the read access pattern?
Looking at a single disk at a time, do your best to make sure all chunks of the same file are in order and adjacent.
You could be smarter than that, but just that would do fine.
The problem is that ZFS basically can't move things.
The one killer feature for me with btrfs is offline deduping (and by extension not having de-duping require a super computer to run). My data has enough duplication that it'd be nice to have, but not worth requiring hundreds of gigs of ram. Being able to fire off a job after importing a large set of data (or maybe yearly-ish) would be awesome and give me a few extra years without having to update my hardware.
In that case you want to know if you optimize for hardware failure as opposed to for performance.
This could be fixed for specific usecases but not all block patterns in general. Just why I posted this.
Also a lot of other fancy features would be broken by pagecache design, so it's a no-go, and instead project focused on reducing duplication between the two.
On the other hand, I have not had much need for defragmenting.
Only in very limited instances. I think ZFS duplicates the inodes and dentries cache, and only file pages when you do something like mmap a file.
The ability to add capacity to a pool by adding a single drive at a time, or the fact that it is readily available on any Linux box.
zfs supports that now
There's a reason the other major non-debian distros have switched to it by default.
I'm still waiting for ubuntu to allow installing using btrfs + fulldisk encryption by default, which is currently a massive issue.
Not sure where you got this from. OpenZFS on Linux is considered stable by the project. It has been rock solid, free of major issues, and considered more than ready for prime time since at least 0.8, and probably much earlier. It’s now at 2.1.
I’ve been using it across multiple environments, including my personal laptop and workstation which maintained the same root-on-ZFS install for 6+ years, including 2 full migrations to new hardware using zfs send. I’ve deployed much larger pools in professional settings and they’ve been rock solid.
Btrfs has had numerous data loss issues in that time. I can only recall one data loss issue in a ZFS on Linux release, several years ago, which was caught very quickly.
Btrfs hasn't had any major data loss issues for the last 5 years (excluding the raid issues) btrfs is much newer than ZFS, so obviously it took longer to be stable, if you're talking about 6+ years ago, Btrfs was obviously not ready yet, but now? It's been the default on OpenSUSE for 5 years and Fedora for 2.
“I can’t believe Nixon won. I don’t know anyone who voted for him.” -- Pauline Kael
I use ZFS on root. Know lots of people who do. Might be your bubble?
That says more about the distributions than about ZFS’s fitness or maturity as a file system.
It’s understandable that many distributions don’t bundle ZFS, since the licensing is still an open debate. Although that’s not so cut-and-dried [1], I wouldn’t expect broad support from distributions unless and until these issues have been tested and proved out one way or the other. No organization wants to insert themselves into a legal skirmish.
The best (and probably only good thing) to come out of Ubuntu’s support for ZFS is the vote of confidence in favor of ZFS’s legality in-base from a major corporate entity. We can hope more distributions pick up on this, but I’m not holding my breath.
But legal issues and technicalities say nothing at all about the relative technical merit of ZFS (or any other file system).
> how many people use it as a filesystem for the linux root? Never seen anyone putting the main OS on zfs
Quite a lot of users, actually. There’s a significant community around ZFS, including an ecosystem of some robust tooling. ZFSBootMenu is evidence enough that people want to run root on ZFS, and that root on ZFS is both feasible and highly desirable. Compare its feature list to what you can achieve with root-on-Btrfs, and ZFS pretty handily comes out ahead as the more powerful file system in terms of real world administrative capabilities.
[1] https://blog.hansenpartnership.com/are-gplv2-and-cddl-incomp...
Although I'd still suggest single-block-device-btrfs on mdadm instead. The per-file RAID in btrfs (/zfs) can skip over unallocated sectors, but mdadm gets to do larger sequential writes with less random seeking. On spinning disks this can very quickly overtake the performance at even lightly filled volumes.
https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...
but for desktop use, it's probably fine. It's been the default for new Fedora installations for over a year now, and I don't see too many Fedora users complaining about their filesystem being hosed.
My current installation is still legacy EXT4 since I upgrade, but at some point I might blow it away and try a fresh install.
All RAID1, backups to object storage.