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.

Comments

Mrs Overstreet?

[TechyImmigrant]

If there's a Mrs Overstreet, she needs to be careful. Linux FS programmers have a bit of a history.

Like the DragonFly BSD approach?

[lambsonic]

Is this the Linux answer to swapcache and the HAMMER filesystem in DragonFly BSD? Of course, a major generalization and oversimplification, but it seems a similar kind of approach to a similar set of problems.

Re:Like the DragonFly BSD approach?

[Anonymous Coward]

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.

Why? What advantages does this have over ZFS?

[UnknownSoldier]

> a modern COW filesystem with checksumming, compression, multiple devices, caching, and eventually snapshots and all kinds of other nifty features

Instead of yet another FS flavor of the month, or year, (Reiserfs, Btrfs, Bcachefs, etc.) and all the man-hours wasted re-solving the same old problems how about just doing it right the first time (ZFS) ?? Because this is what it is turning into. What advantages bachefs have over ZFS??? There is no way in hell I'm going to trust an unproven, buggy, and incomplete FS when we already have one that works.

Fixing the Butr free space shenanigans would have been a step in the right direction: An existing debugged FS.

Reminds me of this xkcd #927: Standards

Re:Why? What advantages does this have over ZFS?

[Anonymous Coward]

Yep, just not included in standard distros due to licensing.

Re:Why? What advantages does this have over ZFS?

[rubycodez]

You are funny, ZFS is a horrible resource pig. Many superior alternatives exist

Re:Why? What advantages does this have over ZFS?

[danbob999]

BTRFS is more ready than ZFS is. It is already pretty stable, in the kernel, and distros are talking about using it as a default FS.
The main problem to its adoption is that most people don't need the extra features over ext4 and don't really care.

Re:Why? What advantages does this have over ZFS?

[Anonymous Coward]

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.

Re:Why? What advantages does this have over ZFS?

[Anonymous Coward]

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.

Re:Why? What advantages does this have over ZFS?

[Anonymous Coward]

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.

Re:Why? What advantages does this have over ZFS?

[fnj]

NO WAY is btrfs even in the same class of reliability and robustness as ZFS. So no, it is NOT production ready. And no, I won't be easily impressed just because some dopey distros take a chance on it.

Re:Why? What advantages does this have over ZFS?

[fnj]

I am running every day 36 TB of raw storage - 24 TB after redundancy is subtracted - in two 6-drive RAIDZ2 ZPOOLs on a CentOS6 box with 8 GB of RAM devoted to ZFS (total installed RAM is 16 GB). Both pools are nearing 90% full. Performance is excellent and problems nil. So you can push well past the 1 TB/GB rule of thumb.

Yeah, if you traverse the entire system listing files, it's a little slow because my RAM ARC cache is so limited, and I have no SSD L2ARC cache. That's an acceptable tradeoff for my purposes.

I have some directories being snapshotted every 5 minutes. The last 24 5-minute snapshots, 48 hourlies, 62 dailies, and 8 weeklies are currently preserved online. 9 of the 24 provisioned monthlies are there; that's how long I've been running the cron job; and no yearlies so far. Snapshots older than 24 5-minute/48 hourly/62 daily/8 weekly/24 monthly are auto-trimmed.

Altogether I can enumerate in real-time (essentially instantly) 607 directory-hierarchy snapshots (sum of number of directory hierarchies snapshotted times number of snapshots in existence for that directiry hierarchy).

Re:Why? What advantages does this have over ZFS?

[mcrbids]

Disclaimer: I ZFS.

We had a problem that ext* just couldn't handle. We have a medium sized filesystem with about 250 million data files that we needed to back up. Every day. Rsync completely failed at the job, taking between 1 and 2 days to do the job.

Desperate to find a solution, we tried ZFS and snapshot replication. Our time to replicate to DR, dropped from days to a few hours, backup storage requirements dropped through the floor, and server load dropped at the same time! This is on a reasonably priced set of systems, Xeon-based intel systems with just 32 GB of RAM and 6x 4 TB drives.

ZFS is pretty decent, and has proven to be more reliable for our use than ext*. However, its licensing presents a developmental pit fall. On Linux, it won't ever be a "first rate citizen" even though the ZoL project has done a great job making it very available. ZFS also has a number of pretty terrible problems:

1) You can't remove a vdev from a ZFS pool without destroying the pool.

2) You can't upgrade a vdev's redundancy level once you've added it to a pool.

This means that, if you're careful, ZFS is wonderful. But it's easy to make a mistake that you can't easily back out of. See the section hating your data to see what I mean.

BTRFS has been "only a few years away now" for quite a few years now. I'm not convinced it will ever reach production ready status. Apparently it has some architectural problems that have been criticized pretty soundly. I'm no longer convinced about the future inevitability of BTRFS.

I sincerely hope that BCacheFS really delivers on these promises, I'd love it!

Re:Why? What advantages does this have over ZFS?

[Bert64]

Because your fairly old and underpowered solaris servers likely had small disks...

Funding Needed

[bezenek]

From Mr. Overstreet's announcement:

PSA: Right now I'm not getting any kind of funding for working on bcachefs; I'm
working on it full time for now but that's only going to last as long as my
interest and my savings account hold out. So - this would be a wonderful time
both for other developers to jump in and get involved, and for potential users
to pony up some funding. If you think this is interesting and worthwhile and you
want to see it completed and upstream - especially if you're at a company that
might make use of it - talk to your $manager or whoever and nag them until they
send me a check :)

Re:Good job

[rubycodez]

Strange, on Earth the internet is not powered by windows servers but rather Linux and BSD ones, nor are smart phones running windows but BSD and Linux. What planet do you live on? The planet of the twats?

Hmmmm

[eyegone]

I guess writing a new filesystem is easier than fixing the existing bugs in bcache itself.