There's been some Friday night kernel drama on the Linux kernel mailing list... Linus Torvalds has expressed regrets for merging the Bcachefs file-system and an ensuing back-and-forth between the file-system maintainer.
Kent developed for like 10 years on his own. He's just having a hard time learning how to play with others, and deal with large priority cycles.
He just needs to know that sometime his changes will get pushed to the next cycle.
bcachefs is way more flexible than btrfs on multi-device filesystems. You can group storage devices together based on performance/capacity/whatever else, and then do funky things like assigning a group of SSDs as a write-through/write-back cache for a bigger array of HDDs. You can also configure a ton of properties for individual files or directories, including the cache+main storage group, amount of data replicas, compression type, and quite a bit more.
So you could have two files in the same folder, one of them stored compressed on an array of HDDs in RAID10 and the other one stored on a different array of HDDs uncompressed in RAID5 with a write-back SSD cache, and wouldn't have to fiddle around with multiple filesystems and bind mounts - everything can be configured by simply setting xattr values. You could even have a third file which is striped across both groups of HDDs without having to partition them up.
For me the reason was that I wanted encryption, raid1 and compression with a mainlined filesystem to my workstation. Btrfs doesn't have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.
ZFS has raid levels, encryption and compression, but doesn't have fsck. So you better have an UPS for your workstation for electric outages. If you do not unmount a ZFS volume cleanly, there's a risk of data loss. ZFS also has a weird license, so you will never get it with mainline Linux kernel. And if you install the module separately, you're not able to update to the latest kernel before ZFS supports it.
Bcachefs has all of this. And it's supposed to be faster than ZFS and btrfs. In a few years it can really be the golden Linux filesystem recommended for everybody. I sure hope Kent gets some more help and stops picking fights with Linus before that.
ZFS doesn't have fsck because it already does the equivalent during import, reads and scrubs. Since it's CoW and transaction based, it can rollback to a good state after power loss. So not only does it automatically check and fix things, it's less likely to have a problem from power loss in the first place. I've used it on a home NAS for 10 years, survived many power outages without a UPS. Of course things can go terribly wrong and you end up with an unrecoverable dataset, and a UPS isn't a bad idea for any computer if you want reliability.
Totally agree about mainline kernel inclusion, just makes everything easier and ZFS will always be a weird add-on in Linux.
Btrfs doesn't have encryption, so you need to do it with luks to an mdadm raid, and build btrfs on top of that. Luks on mdadm raid is known to be slow, and in general not a great idea.
Why involve mdadm? You can use one btrfs filesystem on a pair of luks volumes with btrfs's "raid1" (or dup) profile. Both volumes can decrypt with the same key.
Bcachefs has all of this. And it’s supposed to be faster than ZFS and btrfs. In a few years it can really be the golden Linux filesystem recommended for everybody
ngl, the number of mainline Linux filesystems I've heard this about. ext2, ext3, btrfs, reiserfs, ...
tbh I don't even know why I should care. I understand all the features you mentioned and why they would be good, but i don't have them today, and I'm fine. Any problem extant in the current filesystems is a problem I've already solved, or I wouldn't be using Linux. Maybe someday, the filesystem will make new installations 10% better, but rn I don't care.
ZFS doesn't have Linux fsck has it is its own thing. It instead has ZFS scrubbing which fixes corruption. Just make sure you have at least raid 1 as without a duplicate copy ZFS will have no way of fixing corruption which will cause it to scream at you.
If you just need to get data off you can disable error checking. Just use it at your own risk.
Encryption and compression don't play well together though. You should consider that when storing sensitive files. That's why it's recommended to leave compression off in https because it weakens the encryption strength
bcachefs is meant to be more reliable than btrfs - which has had issues with since it was released (especially in the early days). Though bcachefs has yet to be proven at scale that it can beat btrfs at that.
Bcachefs also supports more features I believe - like encryption. No need for an extra layer below the filesystem to get the benefits of encryption. Much like compression that also happens on both btrfs and bcachefs.
Btrfs also has issues with certain raid configurations, I don't think it yet has support for raid 5/6 like setup and it has promised that for - um, well maybe a decade already? and I still have not heard any signs of it making any progress on that front. Though bcachefs also still has this on their wishlist - but I see more hope for them getting it before btrfs which seems to have given up on that feature.
Bcachefs also claims to have a cleaner codebase than btrfs.
Though bcachefs is still very new so we will see how true some of its claims will end up being. But if true it does seem like the more interesting filesystem overall.
In addition to the comment on the mentioned better hardware flexibility, I've seen really interesting features like defining compression & deduplication in a granular way, even to the point of having a compression algo when you first write data, and then a different more expensive one when your computer is idle.
Btrfs has architectural issues that can not be fixed. It is fine for smaller raid 0/1 but as soon as you try to scale it up you run into performance issues. This is because of how it was designed.
Bcachefs is like btrfs and has all the features btrfs does. However, it also is likely to be much faster. Additionally it has some extra features like tiered storage which allows you to have different storage mediums.
Because bcachefs is btrfs that actually can into RAID systems like raid 5/6 and combinations, and doesn't have licensing problems as zfs, i mean people want zfs that's inside kernel source code by default and bcachefs does exactly this
He accepted Linus's needs as the project head to keep order. He resubmitted the patch set without the contentious parts. It's less than 1/3 the size and doesn't touch code outside of bcachefs. Problem solved.
Honestly, Kent seems pretty reasonable (though impassioned), and bcachefs well probably make it, and Kent will get used to just submitting things at the right time in the cycle.
It's not as bad as it seems. He just doesn't know how valuable working with the provided structure is yet. A lot of innovative thinkers are used to questioning, bending, and tinkering with the rules. He's just still learning how necessary the existing structure is.
I definitely feel bcachefs is much more practical than zfs for home storage, I've used both. I don't use zfs unless it's TrueNAS because of the licensing issues, but bcachefs solves all of that and you can use different sized drives. I look forward to it being stable and glad it's working out. Luckily the only side affect is Linus' regretfulness. 😂
ext4 is intended for a completely different use case, though? bcachefs is competing with btrfs and ZFS in big storage arrays spanning multiple drives, probably with SSD cache. ext4 is a nice filesystem for client devices, but doesn't support some things which are kinda fundamental at larger scales like data checksumming, snapshots, or transparent compression.
What's cool about bcache is that it can have fully tiered storage. It can move data from a hard drive to a SSD and vis versa. It isn't a cache like in ZFS as ZFS wipes the cache drive on mount and adding a cache doesn't increase capacity
To people who just want to browse the web, use Office applications and a few other things, ext4 just works and FAT32 really just doesn't.
I get the point you're trying to make, FAT32 also has a small file size and is missing some features, ext4 is like that to for instance Bcachefs.
But FAT32 (and exFAT and a few others) have a completely different use cases; I couldn't use FAT32 for Linux and expect it to work, I also couldn't use ext4 for my USB stick and expect it to just work as a USB stick.
No. You can layer ext4 with LVM and LUKS to get a lot of features (but not all) that you get with BTRFS or ZFS. FAT is not suitable for anything other than legacy stuff.
I once had the whole FS corrupted and I don't remember if it was XFS or ZFS (probably the latter). Also I like messing around with interesting software that might not support less common filesystems so I just stick with ext4. XFS is great though.
You really can't go wrong with it, in the vast majority of cases.
As much as I would love to say that i like btrfs, it's not without issues. In the 3 years I've used it on my systems, I've already had one instance of corruption, and one more of complete data loss.
Don't have any experience at all with bcachefs, but this is the type of thing where it either works, or it just doesn't, and no one wants it to be the latter
You had corruption with btrfs? Was this with a spinning disk or an SSD?
I've been using btrfs for over a decade on several filesystems/machines and I've had my share of problems (mostly due to ignorance) but I've never encountered corruption. Mostly I just run out of disk space because I forgot to balance or the disk itself had an issue and I lost whatever it was that was stored in those blocks.
I've had to repair a btrfs partition before due to who-knows-what back when it was new but it's been over a decade since I've had an issue like that. I remember btrfs check --repair being totally useless back then haha. My memory on that event is fuzzy but I think I fixed whatever it was bitching about by remounting the filesystem with an extra option that forced it to recreate a cache of some sort. It ran for many years after that until the disk spun itself into oblivion.