In terms of maturity, bcachefs is closer to production quality than reiser4 was, but it's still closer to reiser4 than reiserfs in its lifecycle.
You've built an amazing thing but speaking as another very opinionated dev on the outside who sometimes butts heads with other opinionated devs- please just defer to Linus on this so you can get this in the kernel. Or just have it pushed to the next kernel release (I realize this has already happened repeatedly). Just please don't add a significant feature in a bugfix cycle. And (as mercurial as we all know he is, and as valid as some of your concerns surely are), try to keep the peace with that guy. Do it for the sake of the project. I've been waiting for this to drop for literally years now. I care about it, and I know no one does more than you, and I swear that I know exactly what that's like. It's your brain-baby, the concrete instantiation of your blood/sweat/tears. But... Take a deep breath, swallow, trust the process.
The bands that produced some of the best music had HUGE tensions within them. But you can't let it explode (we all know that some bands did). I made that mistake a year ago, and lost a job I very much cared about. (Perhaps to a fault.) Don't be me. lol
Statistics are funny like that.
Honestly Kent, this continuing baseless fearmongering from you about btrfs is absolutely disgusting.
It costs you. I was initially very interested in bcachefs, but I will never spend my time testing it or contributing to it as long as you continue behave this way. I'm certain there are many many others who would nominally be very interested, but feel the same way I do.
Your filesystem charitably gets 0.001% the real world testing btrfs does. To claim it is more reliable than btrfs is ignorant and naive.
Maybe it actually is more reliable in the real world (press X to doubt...), but you can't possibly know yet, and you won't know for a long time.
If your product is so great its it's own advert. If it has problems spend the limited person power fixing it not attacking the opposition, this is what ciq have done, do better.
> 0.001% the real world testing
Statistics can be quite powerful. If you have a million installs, and your billion-install competitor has 100 problems per million installs, you can make some pretty strong statements about how you rate against that competitor. Just for easy example numbers.
Of course, I've never used bcachefs as a daily driver... nor as a filesystem in general... but I'd love to... lol
This isn't baseless fearmongering, this is "did you think through the failure modes when you were designing the basics".
This stuff comes up over, and over, and over.
Engineering things right matters, and part of that absolutely is comparing and documenting approaches and solutions to see what went right and what went wrong.
This isn't a popularity contest, and this isn't high school where we form into cliques and start slinging insults.
Come up with facts, documentation, analysis. That's what we do. I'm tired of these threads degenerating into flamewars.
I am not a filesystems guy, but I was disappointed when I realized that btrfs did not have a good design for ENOSPC handling.
So I'm curious, does bcachefs design for a benign failure mode when out of space?
Now: I am not saying that bcachefs is yet trouble free enough for widespread deployment, we're still seeing cases where repair needs fairly minor work, but the filesystem may be offline while we get that fixed.
OTOH we also recover, regularly, from absolutely crazy scenarios involving hardware failure: flaky controllers, lightning strikes, I've seen cases where it looked like a head crashed - took out a whole bunch of btree nodes in similar LBA ranges.
IOW: the fundamentals are very solid, but keep checking back if you're wondering when it'll be ready for widespread deployment.
Milestones to watch for: - 3 months with zero data loss or downtime events: I think we may get this soon, knock on wood - stable backports starting: 6.17, knock on wood (or maybe we'll be out of the kernel and coming up with our own plan, who knows) - weird application specific bugs squashed: these have been on the back burner, but there's some weird stuff to get to still (e.g. weird unlink behavior that affects docker and go builds, and the Rust people just reported something odd when building certain packages with mold).
And yes, we've always handled -ENOSPC gracefully.
Are any of these claims verifiable, or even made by anyone other than yourself?
Frankly, without substantiating any claim or even providing any concrete evidence, it reads like trying to badmouth what you perceive as competitors in a desperate attempt to get some traction. Not cool.
I'm not saying everything needs to be a bullet point presentation but in the era of llms to help plug the gaps with this stuff, "look at the mailing list" or "watch irc" isn't much better than anecdotal.
Again, recovering data, laudable. Hell, maybe impressive to compare the situation to equivalents on other fs to discuss why this is better than X. But a simple "we get the data back compared to Y" just reads as Y bashing unless there's metrics, or clear technical reasons as to why you're superior.
I _want_ bcache to be better for numerous reasons. Everyone wins from a better product. But realistically getting there means telling some people that they need to wait.
Frankly if there is a need to support users who demand mainline access to the latest and greatest _NOW_. Adopt/appoint a supported os/distro and roll your own nightly packages into a simple repo. If you have to rush upstream because a user can't cope with "pull your kernel sources from https://...." They can't cope with compiling it correctly so there's little (if anything) to be gained from rushing into mainline next week constantly...
I agree that more thoughtful analysis would be helpful, but I have to work with what I've got :)
One of the recent pull request threads had a user talking about how bcachefs development is being done "the old way", from the earlier days of Linux; less "structure", less process, so that we can move quickly and - critically - work effectively with users.
I liked that comparison, and I think that's a big part of why bcachefs has had the success it's had with users (it's a proven recipe! Linux did displace everything else, after all). And on top of that, we're doing it engineering best practices that have advanced significantly since then. Automated testing, a codebase that heavily uses assertions (there's a lot I've said elsewhere about how to effectively use assertions; it's not preconditions/postconditions), runtime debugging, and more. It started too early to be written in Rust, that's really the only thing I'd change :)
People just need to be patient - this stuff takes time. The core design was done years ago, on disk format was frozen in 6.15, and now we're in a pretty hard freeze and doing nothing but fix bugs. The development process has been working well, it's been shaping up fast.
I don't think there is ambiguity. Either you have some way to objectively corroborate your personal claims, or you don't. Those are called Benchmarks. Performance is a specific type of benchmark test, but it's not the only one.
Either you have those or you don't. Making assertions and claims without benchmarks is not a confidence- or reputation-builder.
(Yes, I know they don't do it "the right way". It still works at the end of the day.)
Data integrity, core IO paths, all the failure modes, all the crazy repair corner cases - these are the hard parts if you really want to get a filesystem right. These are what we've been taking our time on.
I can't claim 100% success rate w.r.t. data loss, but it's been phenomenally good, with some crazy stories of filesystems we've gotten back that you'd never expect - and then it just becomes the norm.
I love the crazy bug reports that really push the boundaries of our capabilities.
That's an attitude that reiserfs and btrfs never had, and when I am confident that it is 100% rock solid and bulletproof I'll be lifting the experimental label.
Who does?
When the MySQL and Postgres projects recommend it, I’ll have a look.