3
points
koverstreet
Joined 1,909 karma
- ZFS is the only filesystem I know of with one, and theirs is pretty incomplete. It does need to be a shared project.
- That does happen sometimes. But look on the bright side; a lot of people are getting crash courses in low level systems debugging, and those are skills that are not as common as they used to be - but they're still important.
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.
- You can do that now via the data_allowed parameter
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.
- The default should be the device's native blocksize, and some devices misreport. You also lose performance if you use a larger blocksize than necessary.
If we can, I'd like to get a quirks list in place, but there have been higher priorities.
- yeah, we'll be supporting 6.18 ongoing.
- Still changing the on disk format as required, but we're at the point now where the end user impact should be negligible - and we aren't doing big changes.
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).
- Distros generally build everything they can as modules these days, including filesystems. No reason not too, we've had initramfs since forever; you can't build everything in that anyone might need to boot their machine.
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.
- I'm here to talk filesystems and technical topics, not to take part in or stir up drama. There's been more than enough of that.
This is hacker news, not drama queen news :)
- It'll happen eventually, it's been a frequently asked for feature.
- 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
- 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.
- 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.
- 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 :)
- 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.
- Oh cool.
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 :)
- FAANG engineeers can't code for shit, but the one thing they did get right was when they jumped on the Rust bandwagon
- I also don't recall anyone ever blaming the WWII, or other generations like this.
Boomers coasted off the success of the postwar era, and now we're all poorer for it.
- soon :)
(obligatory plug for people to jump in and get involved with writing code if they want to see more of this stuff happen)