The main one is how it handles corruption. It has actively been designed to do the exact opposite of what a sane filesystem should do and maximises downtime.
I’ve seen ZFS in production use on pools with hundreds of TBs, clustered together into clusters of many PBs. The people running that don’t even think about BTRFS, and certainly won’t actively consider it for anything.
BTRFS once had data corruption bugs. ZFS also had that, but only in very specific edge cases. That case was taken very seriously, but basically, ZFS has a reputation for not fucking up your bits even close to BTRFS
ZFS was built and tested for use on large pools from the beginning, by Sun engineers from back when Sun was fucking amazing and not a pile of Oracle managed garbage. BTRFS still doesn’t have stable RAID5/6.
ZFS send/recv is amazing for remote replication of large filesystems.
DRAID is kind o the only sane thing to do with todays disk sizes, speeds and pool sizes.
But those are ancillary reasons. I’ll quote the big reason from the archwiki:
The RAID 5 and RAID 6 modes of Btrfs are fatally flawed, and should not be used for "anything but testing with throw-away data”.
For economic reasons, you need erasure coding for bigger pools, either classic RAID5/6 or DRAID. BTRFS will either melt your data in RAID5/6 or not support DRAID at all.
Honestly, if it’s important enough to RAID, it’s important enough to do right and run full fat ZFS.
You could also go the mdadm route with individual disks but ZFS pools are so battle-tested that whatever unholy edgecase you manage to create will almost certainly be something someone has encountered before, and it’s probably well documented somewhere how to recover from
The Linux kernel uses mailing lists so technically it is called a patch.
I think the biggest issue was that Kent had/has a attitude problem. It feels weird to pick a fight with Torvalds since he is kind of known for destroying devs but Kent did it anyway.
What’s the problem with btrfs really?
It is nice but it also feels like it is perpetually unfinished. Is there some major flaw in the design?
The main one is how it handles corruption. It has actively been designed to do the exact opposite of what a sane filesystem should do and maximises downtime.
It shouldn’t be that hard to patch it so that it works around failures. I’m not sure why that doesn’t seem to be a config setting.
I’ve seen ZFS in production use on pools with hundreds of TBs, clustered together into clusters of many PBs. The people running that don’t even think about BTRFS, and certainly won’t actively consider it for anything.
But those are ancillary reasons. I’ll quote the big reason from the archwiki:
For economic reasons, you need erasure coding for bigger pools, either classic RAID5/6 or DRAID. BTRFS will either melt your data in RAID5/6 or not support DRAID at all.
Mostly just the RAID5 and 6 instability, it’s fantastic otherwise. But I’m kinda excited to try out bcachefs pretty soon, as well.
Me too. (And when the author gets a chill pill)
So one should use ext4 for RAID 5&6?
Honestly, if it’s important enough to RAID, it’s important enough to do right and run full fat ZFS.
You could also go the mdadm route with individual disks but ZFS pools are so battle-tested that whatever unholy edgecase you manage to create will almost certainly be something someone has encountered before, and it’s probably well documented somewhere how to recover from
Sweet, thanks for the info
I would use ZFS
I’m not an expert but I’d say mdadm with btrfs on top
Isn’t bcachefs in danger of being removed from the kernel?
Just gotta hope Kent gets his pull requests there in time lol
The Linux kernel uses mailing lists so technically it is called a patch.
I think the biggest issue was that Kent had/has a attitude problem. It feels weird to pick a fight with Torvalds since he is kind of known for destroying devs but Kent did it anyway.