bcachefs storage driver

[cveilleux]

With bcachefs officially mainlined into linux 6.7, has anybody looked into this new filesystem?

It is similar in features to BTRFS and ZFS, so potentially a libcontainers storage driver could be written for bcachefs.

What would the Container Storage Library need in order to consider support for bcachefs?

Would you need mainstream support of bcachefs in popular distributions first?

Packaging of the bcachefs-tools available in supported distros?

Is this something the team could consider developing?

If not, would an outside pull request be considered/accepted or are new storage drivers not welcomed?

Just wanted to get the discussion started around this new filesystem that is getting some attention now.

[giuseppe]

From what I've seen, a specialized driver for a new filesystem doesn't really add much advantage as we've already experienced with BTRFS.

The overlay storage backend we've got now works with many different setups and offers features that will be difficult (if not impossible) to replicate in a different backend for bcachefs, like for example its integration with partial pulls, composefs that are we currently working on right now, as well as additional image stores.

I don't think anyone in the core team will consider such effor, but if someone in the community is interested to play with it and find it useful, it can be considered for inclusion as we did for BTRFS.

[rhatdan]

Sure, but core developers will not support it, and will tell users to move to Overlay if they find issues, or get someone in the community to fix.

[0xFEEDC0DE64]

bcachefs does not support overlayfs at all, unless you are willing to compile an untested specialized kernel with lots of custom configurations by kent, so we really need a bcachefs driver for containers

[giuseppe]

adding a custom driver is a lot of maintainance burden. How would a bcachefs look like? What primitives does bcachefs offer that is worth considering a custom driver?

If overlay doesn't work you can either use a different underlying file system, or use vfs

[MrDrMcCoy]

@0xFEEDC0DE64
bcachefs does not support overlayfs at all, unless you are willing to compile an untested specialized kernel with lots of custom configurations by kent, so we really need a bcachefs driver for containers

This will soon no longer be the case: https://lore.kernel.org/lkml/20250520051600.1903319-1-kent.overstreet@linux.dev/

@giuseppe
What primitives does bcachefs offer that is worth considering a custom driver?

Its snapshot/subvolume support can be used much in the same way as btrfs/ZFS, it has better compression options than they do, (eventually) uses erasure-codes for more efficient and flexible redundancy, and has a better caching/tiering strategy than any other open source storage project I have yet seen. The last one is the feature most of us want for the short term. I have used it to great effect in a system with ~48 slow drives on a single 6Gbps SAS link and several Optane drives as a cache tier in front, each with different compression settings. It felt like everything was running on flash.

or use vfs

This could work in the short term. Would you please direct us to an example, not necessarily with bcachefs/containers? As a search term, it returns rather a lot of information that is not directly helpful. From what I understand, it is an implicit feature that exists between all filesystems and the applications that access them. If there is a way to use it for additional layering between a real and overlay filesystem, that would be a welcome concept that is entirely new to me.

[giuseppe]

bcachefs was dropped from the upstream kernel, so I think it is safe to just close this for now

[mtrmac]

I agree — for now, at the very least.

---

Directionally, we’ve been talking about composefs for cross-root file sharing, pulls populating layers without holding locks in any order, and the like, which don’t work well with the snapshot-based strict parent/child layer relationships; so, using native filesystem snapshot features is not obviously attractive; using overlay/composefs/something like that on top of any filesystem would make most of the c/storage code independent of filesystem choice.

Admittedly, I aesthetically, and due to significant maintainability concerns, really don’t like the many features and layers of indirection and optional code paths that have been crammed into the overlay graph driver — but it did happen, and writing a new graph driver from scratch would mean that that graph driver would either have to give up on many of those features (at least initially), or replicate all that complexity, at the cost of ~doubling the maintainability concerns.

(One possible way to solve this would be to move a lot of the features out of the overlay graph driver into the generic code. Perhaps possible (perhaps not, for the features that are incompatible with composing overlays in arbitrary order!), but a lot of work.)

---

Of course, this is an open source codebase, and anyone can go and implement that — and we’d probably prefer that code to live in the primary codebase rather than as a separate fork — but until/unless that starts happening, I don’t think it’s valuable to track it as an action item.

So, closing; that doesn’t prevent revisiting the discussion if something changes (upstream support, widespread usage, or a pending code contributioin).