A new bcachefs release

[Posted March 16, 2017 by corbet]

Kent Overstreet has announced a new major release of his bcachefs filesystem. Changes in this release include whole-filesystem encryption, backup superblocks, better multiple-device support, a user-space filesystem checker, and more. "We can also now migrate filesystems to bcachefs in place! The bcache migrate command takes an existing filesystem, fallocates a big file in it, creates a new filesystem (in userspace) on the block device but using only the space reserved by that file it fallocated - and then walks the contents of the original filesystem creating pointers to all your existing data." There is an on-disk format change, but there's a chance it's the last one.

(Log in to post comments)

Posted Mar 16, 2017 19:16 UTC (Thu) by SEJeff (guest, #51588) [Link]

Are they actually building something better than btrfs / ext4, or are they spreading hype? That seems like a pretty tall order.

A new bcachefs release

Posted Mar 16, 2017 19:53 UTC (Thu) by koverstreet (subscriber, #4296) [Link]

I often hear from users that it's more reliable for them than btrfs was :)

A new bcachefs release

Posted Mar 17, 2017 4:25 UTC (Fri) by raof (subscriber, #57409) [Link]

One of the use-cases for which it's just better is having a fast SSD in front of a large HDD. You can do that for btrfs or ext4 by shoving bcache underneath, but that's more complex and less flexible if, for example, you want to stick a fast SSD in front of two large duplicated HDDs.

I presume you could implement this natively in btrfs, too. They're both CoW filesystems, so they've both got roughly the same sensible-implementation space.

A new bcachefs release

Posted Mar 17, 2017 4:45 UTC (Fri) by SEJeff (guest, #51588) [Link]

Why not just use dm-cache in that case? Works great and I've used it with NVME flash + spinning rust quite successfully.

A new bcachefs release

Posted Mar 17, 2017 5:37 UTC (Fri) by koverstreet (subscriber, #4296) [Link]

Less likely to eat your data. bcachefs has fsck, dm-crypt does not.

That criticism of course applies bcache too. bcachefs is in part a much improved, much more robust and mature version of (the core parts of) bcache.

Also, doing caching in a filesystem is much more ideal than caching a block device - the cache itself may be COW, but writes to the block device (writethrough writes, flushing dirty data) are update in place from the cache's POV, which makes cache coherency a real pain. I am very happy to see all the code for writeback cache coherency in bcache die.

A new bcachefs release

Posted Mar 23, 2017 18:05 UTC (Thu) by msnitzer (guest, #57232) [Link]

s/dm-crypt/dm-cache/ ? dm-cache has cache_check (like fsck for dm-cache)

A new bcachefs release

Posted Mar 17, 2017 6:32 UTC (Fri) by raof (subscriber, #57409) [Link]

In addition to Kent's answer - doing this tiering at the FS level allows more flexibility. Things like attributes to set to pin to/exclude from the fast tier. Mark my Music/ directory as excluded from promotion to the fast tier, even though they're read reasonably frequently. Mark files used at boot as excluded from eviction from the fast tier, even though they're read infrequently.

A new bcachefs release

Posted Apr 2, 2017 23:54 UTC (Sun) by mikemol (subscriber, #83507) [Link]

I don't know. I think I'd prefer semantics presented at the block I/O layer to communicate those properties. It could make cache development much more portable. Tiering pririties, persistence preference, access hints, I/O pattern hints.

Available to all filesystems. And the development improvements can be centralized

A new bcachefs release

Posted Apr 3, 2017 15:29 UTC (Mon) by koverstreet (subscriber, #4296) [Link]

What you're missing is that there's huge overlap in the functionality needed to implement a cache and a filesystem; separating them means massive duplication of effort in both lines of code and in actual work at runtime (it's _less efficient_ to have the cache implemented separately underneath the filesystem, it's a lot like stacking one filesystem on top of another).

A standard API for communicating hints - tiering priorities, persistent preference, etc.? That makes sense - but the whole point of a standardized API is so that you can abstract away the implementation and do that however makes the most sense.

A new bcachefs release

Posted Mar 22, 2017 1:47 UTC (Wed) by flussence (subscriber, #85566) [Link]

This looks very real and not hype at all. Compare Tux3 and Reiser4, both of which have seemingly vanished off the face of the internet without ever getting upstreamed.

A new bcachefs release

Posted Mar 22, 2017 3:18 UTC (Wed) by SEJeff (guest, #51588) [Link]

I worked directly with Daniel Philips (tux3 author) and am pretty certain it isn't dead, but is moving glacially slow since one of the main contributors stopped actively working on it.

A new bcachefs release

Posted Mar 16, 2017 20:37 UTC (Thu) by dkg (subscriber, #55359) [Link]

Glad to see this kind of experimental work happening, and being active! A few thoughts about the crypto from a brif skim (please correct me if i'm mistaken or confused!)

the wiki page on encryption says:

In particular, the goal is to be secure even when the attacker controls the storage device itself, and can see reads and writes as they happen and return arbitrary data from read requests.

This is a pretty bold claim -- it sounds like the target is something analogous to Oblivious RAM, which usually comes with a pretty hefty price tag in terms of performance.

Perhaps the claim needs to be watered down a bit, or the word "secure" needs a bit more clarity?

Also, the approach seems to focus on encryption of the full filesystem instead of per-directory or per-file encryption. but these things don't need to be at odds. In fact, per-file encryption can go quite well with full-disk encryption. In particular, per-file encryption makes robust deletion easier; it means that as long as you can scrub a single key you can ensure that a file is unrecoverable, instead of having to track down every copy of it that might reside on the disk. If the per-file key is stored in the metadata, and that metadata is log-structured, it might still be challenging to ensure that per-file keys are scrubbed, though.

Have the authors of bcache thought about secure deletion as a feature for encrypted filesystems?

A new bcachefs release

Posted Mar 17, 2017 21:26 UTC (Fri) by lmb (subscriber, #39048) [Link]

I wonder if Ceph could leverage this for BlueStore. Or how performance with bcachefs and FileStore compares.

A new bcachefs release

Posted Mar 23, 2017 22:01 UTC (Thu) by walters (subscriber, #7396) [Link]

I know naming is hard, and I understand the bcache -> bacachefs transition but...having "cache" in the name of a filesystem intended to be a primary store is...weird. bcfs?

A new bcachefs release

Posted Mar 23, 2017 22:38 UTC (Thu) by bronson (subscriber, #4806) [Link]

pronounced "beakface"

A new bcachefs release

Posted Mar 24, 2017 7:01 UTC (Fri) by raof (subscriber, #57409) [Link]

I've suggested bosfs: Btree Object Store FS :)

A new bcachefs release

Posted Mar 25, 2017 0:00 UTC (Sat) by jcrawfordor (guest, #114167) [Link]

The in-place conversion trick is very, very cool. But it seems to be oriented towards people who might want to switch over on a daily-driver device - might be appealing to the wrong crowd for trying out a relatively new file system. Still, I'm tempted to take the plunge myself.