Slashdot Mirror
Meet Linux's Newest File-System: Bcachefs
An anonymous reader writes: Bcachefs is a new open-source file-system derived from the bcache Linux kernel block layer cache. Bcachefs was announced by Kent Overstreet, the lead Bcache author. Bcachefs hopes to provide performance like XFS/EXT4 while having features similar to Btrfs and ZFS. The bachefs on-disk format hasn't yet been finalized and the code isn't yet ready for the Linux kernel. That said, initial performance results are okay and "It probably won't eat your data — but no promises." Features so far for Bcachefs are support for multiple devices, built-in caching/tiering, CRC32C checksumming, and Zlib transparent compression. Support for snapshots is to be worked on.
Definitely not like HAMMER. Every new filesystem in the past 15 years has used b-trees. You have to because traditional block tables don't scale to the huge disks we have today. (At least, that's the conventional wisdom.) Copy-on-write follows naturally from using a b-tree data structure. So that's definitely not new, either.
HAMMER has so many other design goals that bcachefs isn't even in the same league. For one thing, HAMMER supports online multi-machine replication. HAMMER2 will support multi-master replication.
And unlike all the other Linux filesystems in development, HAMMER (1) actually exists in final form and (2) is stable. The last useable b-tree based filesystem that emerged from the Linux world and gained any traction was ReiserFS, which officially released in 2001. XFS is the most widely used b-tree FS on Linux, but it originated at SGI on IRIX in 1993.
bcachefs looks dead in the water to me. It currently doesn't match the performance of ext4. The author claims there's plenty of room for improvement. Well, of course there is for any proof of concept. But there's also a crap-ton of work to do for correctness and recovery. Correctness and recovery is the achilles heel of b-tree based file systems. Making b-tree filesystems performant while keeping them robust is extremely difficult. What differentiates all the contenders are the way they approach optimization, correctness, and recovery. The strategies invariably evolve to become extremely complex--both the design and the code. bcachefs hasn't appeared to even scratch the surface in that regard.
The optimism of the author suggests to me extreme naivety. I wouldn't touch anything he writes with a 10-foot pole.
Wrong. If you have enough RAM (about 4x what you would normally estimate you need) and a fast enough CPU and keep your storage pool small, then it is not a hog. I wish people here would stop trying to mislead us about ZFS.
You know that www.phoronix.com lost data due to BTRFS recently? The author, Michael, wrote an article on the corrupted data using BTRFS this month. He deemed it not to be production ready. And if you read the forum comments on the article, lot of people wrote that they also got corrupted data due to BTRFS. Not production ready.
Yeah, that clearly was die to BTRFS, totally unrelated to running a git master kernel.
Not 4.2.x.
Not 4.2.
Not 4.2-rc.
Linus' git master.
In production.