Linus Torvalds Begins Expressing Regrets Merging Bcachefs

This. Well said.

Kent is reasonable, and sees Linus's need to keep order. I think he just pushes it sometimes, and doesn't understand how problematic that can be.

That said - he has resubmitted an amended version of the patch, that doesn't touch code outside of bcachefs, and is less than 1/3 the size.

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.

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.

Also because it's meant to be an enterprise level filesystem like ZFS, but without the licensing baggage. They share a lot of feature sets.

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.

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 think he will learn to integrate with the Linux core team over time.

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.

You might as well say use fat32 it just works.

The article is not about which filesystem to use or not, but about the size and contents of the patches submitted in relation to bcachefs. It seems that the submitted changes which should have been just fixes also contain new functionality. Though it is very nice to see how active and enthusiastic the development of bcachefs is, mixing fixes with new functionality is hard to review and dangerous as it can introduce additional issues. Again, while I appreciate Kents work, I understand Linus' concerns.

Torvalds rejected the merge, and that's pretty much what he said - no one is using bcachefs.

There's no reason for a "fix" to be 1k+ lines, these sorts of changes need to come earlier in the release cycle.

I'd consider btrfs if they finally make their raid5/6 implementation stable. I want to work with multiple disks without sacrificing half of my storage.

Does it have native encryption?

For now we have btrfs. Just keep in mind its limitations

It isn't really stable yet so I wouldn't use it regardless