Interview with Kent Overstreet (Bcachefs) [audio]
linuxunplugged.com
linuxunplugged.com
Why is 512 the default and, if 4096 is better, why is this not the default instead?
If we can, I'd like to get a quirks list in place, but there have been higher priorities.
I'll queue this up to listen though I'm always afraid because I think Chris has gone pretty deep into conservative politics and that has the tendency of really pissing me off (though he's not as bad as Lunduke).
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 :)
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.
I currently run NixOS with ZFS-on-root, and because ZFS is also out-of-tree, the "stable" ZFS version in nixpkgs isn't always compatible with the most recent stable kernel. to keep things simple I tend to just stick with the LTS kernels.
previously when I've tried to experiment with bcachefs on NixOS I ran into a catch-22 where I needed to upgrade to a newer kernel to get bcachefs support but doing so wouldn't be compatible with ZFS.
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...)
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 :)
related, plymouth integration to let users know when their machine is booting up if a drive or the filesystem is unhealthy
Another use case would be on a handheld like Steam Deck: internal SSD tiered with a microSD for unused games I keep installed 'just in case'.
I would even want it on my home NAS. Instead of a separate root SSD and all my files on an HDD ZFS array (maybe with smaller cache SSDs), combine it all into a single bcachefs filesystems. Maybe with a subvolume root that stays pinned to the SSD(s). And also being able to use the full capabilities of different size drive unlike ZFS because it's a home NAS for cheap. No erasure coding yet though, so I'm in no rush to migrate my home NAS
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.
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.
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.
I am grateful that you make accessing support quite easy by being available on the #bcache IRC channel with a lot of community support as well, but it is sometimes hard to fix these issues -- in my case I was usually in a VGA console without network access, so I couldn't simply export information/logs/diagnostics to show you without pulling out my phone camera etc. and that becomes a bit tedious in itself. It is partly my fault for using bcachefs for the root filesystem, with encryption etc. but I also knew what I was in for and I wanted to help provide the feedback and experience needed to help out.
It is just that, after awhile, I felt like I kept running into issue after issue, and I kind of just gave up. I do run bcachefs for a secondary drive that is used for storage purpose and it has been great. But yeah, I think running as root fs is just a scary proposition, especially if you don't want to put in the hard yards to diagnose and fix issues as they come and be on top of them. I used Arch, so I was at the time getting the latest version of bcachefs and upgrading constantly.
If you look at the field of filesystem developers and kernel developers, we don't have nearly as many young people getting involved and learning this stuff as we used to, and that's a problem. We need a pipeline of people building deep expertise, and if even a tiny fraction of the people getting involved with the bcachefs community start developing an interest and learning this stuff, that's a success.
Six months ago was also still a very hectic time for debugging and stabilization, it's definitely gotten better.
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.
Sorry. Not a question, just a feature request.
Dang, I really have to start reading up on Linux again. Falling behind.
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?
ZFS did a bunch of stuff right, it's just a much older design; pre-extents, and based on the original Unix filesystem design - filesystem as a database was still unproven at the time.
They were just working incrementally, which for the amount of new features ZFS already had was the smart decision at the time.
Any chance for different encryption keys per subvolume?
As long as the testing pipelines are in place to make sure the dkms module builds on every distro configuration (a good chunk of that is still manual, but there's a project to improve the test infrastructure) - in practice, no one will notice.
I wouldn't have noticed the DKMS switch on my NixOS laptop if I didn't know it was happening.
If you build bcachefs as a module yourself (via DMKS or directly), it works the same as if you got it with your distro.
If you use bcachefs as root, the danger is booting with a kernel that lacks the module.
I hate that bcachefs is not in the kernel, and my primary distro does not use DKMS. But, if you can get a module built, there is no loss of functionality or performance.
(obligatory plug for people to jump in and get involved with writing code if they want to see more of this stuff happen)
Just after reconcile, I landed a patch series to automatically run recovery passes in the background if they (and all dependents) can be run online; this allows the 1.33 upgrade to run in the background.
And with DKMS, users aren't having to run old versions (forcing a downgrade) if they have to boot into an old kernel. That was a big support issue in the past, users would have to run old unsupported versions because of other kernel bugs (amdgpu being the most common offender).
kinda makes me want to rebuild part of my homelab with bcacheFS
This is hacker news, not drama queen news :)
Same thing.