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.

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 :)

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

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.

Dang, I really have to start reading up on Linux again. Falling behind.

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.

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.

This is hacker news, not drama queen news :)