Happy to answer questions about all things bcachefs or what-have-you.
just please no more questions about whether or not bcachefs will be in the kernel, I've been asked that enough :)
sho_hn•1h ago
Well, do you think it will be in mainstream distributions?
koverstreet•1h ago
Do Arch and NixOS count? We're in the core package repositories for them, and have packages available for a list of others.
We're not aiming to be in GUI installers yet, that'll be sometime after taking the experimental label off. We're still going slow and steady; I don't think about doing things that will bring in more users until incoming bug reports are dead quiet (or as close to it as they ever get), and the userbase has been going up plenty fast all on its own by the activity I see.
So, sometime next year we'll be working on distro stuff again. Dunno when, I expect another spike in new users and bug reports when I take the experimental label off.
BlackLotus89•1h ago
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...)
koverstreet•1h ago
I'm hoping to have erasure coding done sometime in the first half of next year (knock on wood).
While reconcile was getting done we got a detailed outline of where EC resilvering is going to plug into that, so it's not looking like a huge amount of work anymore - and there's been people testing EC and reporting the occasional bug, it's been looking pretty solid.
We did some performance testing not too long ago, and it looked like we were in better shape than I thought. I'm still more interested in tracking down performance bug than shaving cycles and going for raw IOPS.
And the userbase isn't complaining about performance at all, aside from the odd thing like accounting read being slow (just fixed a couple issues there) or lack of defrag.
After debugging and stabilization, it's going to be more about usability, fleshing out missing features, more integration work (there's some systemd integration that needs to happen in the mount path), telemetry/introspection improvements (I want all the data I can get for stabilization, and json reporting would be good for lots of things).
So, if you're asking if you can help, that's a decent list to start from :)
BlackLotus89•1h ago
Oh I'm already active on irc and still have to send you a few things, but sure always eager to oblige.
LeFantome•14m ago
Hoping systemd will remain optional
koverstreet•11m ago
yes, it will. But we do want to communicate properly with systemd and let the user know what's going on if mount has to take awhile because of some sort of recovery (instead of timing out), and various other things.
related, plymouth integration to let users know when their machine is booting up if a drive or the filesystem is unhealthy
throwawaypath•1h ago
Since bcachefs no longer mainlined (DKMS) and therefore sits in the same class as ZFS, why would/should I migrate from ZFS to bcachefs?
brendoncarroll•1h ago
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.
koverstreet•1h ago
Scrub went in in 6.15. I think 6.17 might've been when it was fully solid; it took a bit for some bugs to shake out in the self healing paths.
commandersaki•1h ago
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.
koverstreet•1h ago
How long ago was this?
We've been cranking through bugs fast, and there are still bug reports coming in but the severity and frequency has declined drastically, while the userbase has gone up; polling the userbase it's been stabilizing fast.
But we won't really know we're there until we're there, so the main thing I can say is: if you report a bug like that, it'll get looked at fast; the debugging tools are top notch.
rolandog•1h ago
What I've heard is that Kent is very proactive in listening to any and all bug reports to chase down root causes of issues like yours. I'm sure that any information you send his way to try to reproduce the issue would be helpful.
lastpasstwitter•1h ago
Thanks for answering! Can you share some recent benchmarks comparing bcachefs vs zfs vs extra...etc?
octoberfranklin•35m ago
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.
cyberax•28m ago
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.
razighter777•27m ago
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?
throw7•2m ago
Unfortunately there doesn't seem to be any questions and answers about why bcachefs isn't in the kernel? It was but now it isn't. There was some hemming and hawwing about "testing"?
koverstreet•2h ago
Happy to answer questions about all things bcachefs or what-have-you.
just please no more questions about whether or not bcachefs will be in the kernel, I've been asked that enough :)
sho_hn•1h ago
koverstreet•1h ago
We're not aiming to be in GUI installers yet, that'll be sometime after taking the experimental label off. We're still going slow and steady; I don't think about doing things that will bring in more users until incoming bug reports are dead quiet (or as close to it as they ever get), and the userbase has been going up plenty fast all on its own by the activity I see.
So, sometime next year we'll be working on distro stuff again. Dunno when, I expect another spike in new users and bug reports when I take the experimental label off.
BlackLotus89•1h ago
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...)
koverstreet•1h ago
While reconcile was getting done we got a detailed outline of where EC resilvering is going to plug into that, so it's not looking like a huge amount of work anymore - and there's been people testing EC and reporting the occasional bug, it's been looking pretty solid.
We did some performance testing not too long ago, and it looked like we were in better shape than I thought. I'm still more interested in tracking down performance bug than shaving cycles and going for raw IOPS.
And the userbase isn't complaining about performance at all, aside from the odd thing like accounting read being slow (just fixed a couple issues there) or lack of defrag.
After debugging and stabilization, it's going to be more about usability, fleshing out missing features, more integration work (there's some systemd integration that needs to happen in the mount path), telemetry/introspection improvements (I want all the data I can get for stabilization, and json reporting would be good for lots of things).
So, if you're asking if you can help, that's a decent list to start from :)
BlackLotus89•1h ago
LeFantome•14m ago
koverstreet•11m ago
related, plymouth integration to let users know when their machine is booting up if a drive or the filesystem is unhealthy
throwawaypath•1h ago
brendoncarroll•1h ago
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.
koverstreet•1h ago
commandersaki•1h ago
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.
koverstreet•1h ago
We've been cranking through bugs fast, and there are still bug reports coming in but the severity and frequency has declined drastically, while the userbase has gone up; polling the userbase it's been stabilizing fast.
But we won't really know we're there until we're there, so the main thing I can say is: if you report a bug like that, it'll get looked at fast; the debugging tools are top notch.
rolandog•1h ago
lastpasstwitter•1h ago
octoberfranklin•35m ago
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.
cyberax•28m ago
Sorry. Not a question, just a feature request.
razighter777•27m ago
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?