It's not as battle-tested like ZFS with 15+ years of field usage, but it's good enough for me and other users.
There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/
Those numbers are NASty alone. There are more users on other systems.
15+ years of ZFS code is also often said as being a nearly unmanageable pile of mess, supposedly to the point that there’s some of the code that maintainers are afraid of touching, and with plenty of unresolved weird bugs (which I experienced myself with data loss).
Sometimes starting fresh with one coherent codebase and all features design baked in from the start might be better.
It takes 10+ years for any storage engine to iron out all the wrinkles, get it to a state where it's both fast enough, and you can trust it to not lose data. It's stupid to throw it away once it reaches that point.
People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.
I'm using my filesystem since Dec 2024 and it's closer to 100TiB than 10TiB now. I once had an issue that was quickly solved by Kent and now it's stable for me.
Yes, I regret all that drama that I've witnessed. But I'm happy it's way past that now. Kernel can be developed in its pace and bcachefs develops in its own pace.
Without upstreaming it wouldn't get traction it have now.
I agree that things could be managed better to keep it in the upstream but without upstraming we would be in deeper woods than we are now and still a lot of more users is needed to get even more traction and make it even more bulletproof with real-world testing.
There's a NAS appliance called NASty and it shares publicly usage stats: https://nasty-telemetry.pages.dev/ Those numbers are NASty alone. There are more users on other systems.