The Linux kernel has well-defined internal interfaces for character streams, block devices, block-erase devices (mtd), and extent devices (LVM).

Has it been considered to have an official (but not exposed to userspace) "btree device" interface?

The idea being that you could write composable wrappers for btree devices the way you can write composable wrappers for block devices (dmsetup, etc). And have a common interface for these kinds of devices -- the kernel has at least two large and well-developed btree-on-a-block-device implementations (bcache/bcachefs and btrfs). Both of these implementations have been criticized as being quite monolithic and not as unixy ("many small sharp tools") as LVM/dmsetup are.

Since bcachefs no longer mainlined (DKMS) and therefore sits in the same class as ZFS, why would/should I migrate from ZFS to bcachefs?

Actually listened to the podcast before. Happy that everything with the kernel situation kinda seemed to work out for you.

You kinda talked about ec already, but is there an ETA for resilvering?

You were talking about Valve helping in a big way. Was this monetary or development work? If development I would be interested because a while ago I know you do mainly correctness and features right now, but on the phoronix forum you were talking about low hanging fruits for performance work. Was that something of interest to valve/is it something being done right now to make bcachefs a good fs for gaming (whatever that means...)

This isn't really a question.

I love the idea of bcachefs, it gives a lot of the features of btrfs but includes encryption which means no luks song and dance. But having played around it on my laptop and raspberry pi(s), as root filesystem, it just can't be trusted at the moment. I can't remember the exact problem but I ran into bugs jumping to a new version of the kernel where bcachefs stopped working, and having to downgrade but then the format had changed (I think I caused this), and I was just in a completely broken state. I really wanted to figure it out, but after contemplating after the fact, I just don't want to deal with those kind of headaches for now.

I want to be able to use it in a way that I can rely on it for say the next 10 or 20 years, but it just isn't in that state. I can only feel comfortable using it on data or systems that I am not vested in.

Thanks for answering! Can you share some recent benchmarks comparing bcachefs vs zfs vs extra...etc?

I'd love to have configurable tiered storage with delayed migration. To let the spinning rust drives stay off in deep sleep for days, unless the frontend caches don't have the data.

Sorry. Not a question, just a feature request.

Well, do you think it will be in mainstream distributions?

Hi,

I listened to the podcast it was interesting.

Gonna throw some questions you may or may not have gotten.

Are special devices like metadata or write-ahead log devices on the roadmap? Or distributed raid / other exotic raid types?

It would be interesting to hear your thoughts on these.

What do you think zfs got right with this and what did they get wrong?

Forgive a bit of ignorance on this as it might be a dumb question, but now that bcachefs is a kernel module and not part of the kernel directly, is it still realistic for people to run bcachefs as their root filesystem? Do you know anyone doing this?

I was hoping to use bcachefs to have one pool with subvolumes for root (encrypted by tpm), and for the home folders (also encrypted but with different keys, for example for systemd-homed use).

Any chance for different encryption keys per subvolume?

I'm a happy bcachefs user. Haven't had any issues on a simple mirrored array, which I've been running since before it was in (and out) of the kernel. It's the best filesystem in 2025. Thank you for all your work.

What is the status of scrub? Are there any technical barriers to implementing it, or is it just prioritization at this point? FWIW I think there are probably a lot of sysadmin types who would move over to bcachefs if scrub was implemented. I know there are other cooler features like RS and send/receive, but those probably aren't blocking many from switching over.