Hacker News Reader

Comment by mcpackieh | Hacker News Reader

I have been more than satisfied with single-drive Btrfs with OpenSUSE so far, but nevertheless I can't wait for bcachefs to prove itself. On paper at least, bcachefs seems like the most attractive of the three.

View on HN

ZFS will still be preferable for production for a long while until bcachefs has proven itself, and bug reports slow down. That said, I'm also stoked for bcachefs.

ZFS has always appeared to me like a bloated mess. Btrfs is more minimal, but too much so, in that it doesn't do parity (at least very reliably), which sucks because I don't always want mirroring. And it has a reputation for gobbling your data up.

If bcachefs can provide all the most useful features of ZFS, while being minimal and baked into Linux by default, man that will be amazing.

bcachefs's caching (foreground_target, promote_target, background_target) seems more straight forward than ZFS's ZIL/L2ARC stuff since with bcachefs you can use the same device for accelerating writes and reads of frequently accessed files, while (from what I understand) with ZFS you need two partitions, one for each. I'm not a ZFS expert by any means so maybe I've got the wrong ideas, but bcachefs seems a lot more elegant and straight forward in many regards. Still, I'm not jumping to adopt a brand new filesystem.

What does bcachefs need that it doesn't have?

I worded it weirdly. It has what it needs already I think, but I'm saying: if it can reliably and efficiently do all the most useful functions of ZFS, while being built-in to Linux, and not starting off terribly bloated, that will be fantastic.

Going by the most recent Phoronix benchmarks it still needs a fair bit of optimization work. Of course, I'm glad that Kent is focusing on squashing bugs and polishing the architecture first.

Reply on news.ycombinator.com