Quote from webpage: "The COW filesystem for Linux that won't eat your data"
Quote from webpage: "It's the job of the filesystem to never lose your data: anything that can be repaired, will be."
Quote July 2025: "I've been digging through the bug tracker and polling users to see what bugs are still outstanding, and - it's not much. So, the experimental label is coming off in 6.18."
I was a big fan of bcachefs and was looking forward to deploying it across ~100 machines in production. Unfortunately, the removal from the mainline kernel has seriously undermined its credibility for use within a company environment.
A filesystem needs time to mature, and that's fine — but the official webpage should clearly display a warning that this is still experimental and that its long-term support situation is uncertain. People evaluating it for production use deserve to know what they're getting into.
Have you looked at the history of data loss bugs in other filesystems?
If you look at actual data - frequency of user impacting data loss bugs - bcachefs has been doing quite a bit better than other filesystems have /after/ they've dropped the experimental level.
We just live in the age of hype and overhype and excitement that turns into drama. Everyone just needs to chill out :)
And I don't hide stuff like this: compare the impact of the bug itself to what you'd see in other filesystems. We knew basically from the first report what caused it, were able to communicate to users what happened, it wasn't random, it wasn't silent data loss - error messages were good and it was able to understand what was going on.
Talk to people who are actually using it. I know of quite a few people who are now migrating from ZFS because they want something more reliable.
Fair point, and I appreciate the transparency around data loss bugs.
How does it look about long-term sustainability? Looking at the git history, ~97% of bcachefs commits are yours. What happens if you step back, burn out, or can't continue for any reason? Is there a fallback plan? A community or team that could realistically take over?
For anyone evaluating this for production use in a company, that's the question that matters most. A filesystem isn't a library you can swap out — you're locked in for years. The technical quality can be excellent and it still won't pass a risk assessment if it depends on a single person.
I'm not the only person who knows the codebase well enough to do actual work (there's at least one other person I'd be comfortable with giving commit access to), and it's clean and documented pretty well for a filesystem.
And the sustainability equation just changed dramatically, thanks to Claude.
I've been using it the past week for a lot of stuff, and I should really write something longer up, but suffice it to say that I'm impressed. It can't do much independently yet, but it's been able to handle a /lot/ of the grunt work - the other night I had it go through open Github issues, fix what it could and take notes on the rest, and I came back to 8 patches for actual bugs, all of them correct, with excellent commit messages. Holy shit, we're living in the future :)
It can't design for shit, it doesn't understand performance implications when writing code (I've noticed this repeatedly); most of how I'm using it is "pair programming". But I'm finally feeling like I'll be able to take a vacation in the near future and still keep up with everything.
Two other people are using it (with heavy review, actively telling it to go back and research topics more) for a big update to the Principles of Operations. Nice.
Basically, the sustainability aspect comes down to writing clean, maintainable, well documented code - and I think I've accomplished that. One holy shit moment the other day was watching Claude navigate /and understand/ btree and journalling code - and making the connection between the way I use assertions and linear typing/dependent typing. All those years spent on that code developing new ways of thinking about and using assertions to make that stuff practical for one person to do... it's paid off.
Beyond that, the real challenges are pushing the boundaries of how introspectable, understandable and transparent complex systems code can be for the end user - and bcachefs is pushing boundaries there. Making a habit of writing pretty printers for absolutely everything means that now our tracing is the best you'll see in software like this, and well integrated with 'bcachefs fs top'. The timestats stuff that I started well over a decade ago - we've now got a new 'bcachefs fs timestats' interface for that, which is already making debugging performance issues dramatically easier than it has been in the past.
Quote: "you could lose data"
Quote from webpage: "The COW filesystem for Linux that won't eat your data"
Quote from webpage: "It's the job of the filesystem to never lose your data: anything that can be repaired, will be."
Quote July 2025: "I've been digging through the bug tracker and polling users to see what bugs are still outstanding, and - it's not much. So, the experimental label is coming off in 6.18."
I was a big fan of bcachefs and was looking forward to deploying it across ~100 machines in production. Unfortunately, the removal from the mainline kernel has seriously undermined its credibility for use within a company environment.
A filesystem needs time to mature, and that's fine — but the official webpage should clearly display a warning that this is still experimental and that its long-term support situation is uncertain. People evaluating it for production use deserve to know what they're getting into.
Would have loved to use it.
Have you looked at the history of data loss bugs in other filesystems?
If you look at actual data - frequency of user impacting data loss bugs - bcachefs has been doing quite a bit better than other filesystems have /after/ they've dropped the experimental level.
We just live in the age of hype and overhype and excitement that turns into drama. Everyone just needs to chill out :)
And I don't hide stuff like this: compare the impact of the bug itself to what you'd see in other filesystems. We knew basically from the first report what caused it, were able to communicate to users what happened, it wasn't random, it wasn't silent data loss - error messages were good and it was able to understand what was going on.
Talk to people who are actually using it. I know of quite a few people who are now migrating from ZFS because they want something more reliable.
Fair point, and I appreciate the transparency around data loss bugs.
How does it look about long-term sustainability? Looking at the git history, ~97% of bcachefs commits are yours. What happens if you step back, burn out, or can't continue for any reason? Is there a fallback plan? A community or team that could realistically take over?
For anyone evaluating this for production use in a company, that's the question that matters most. A filesystem isn't a library you can swap out — you're locked in for years. The technical quality can be excellent and it still won't pass a risk assessment if it depends on a single person.
I'm not the only person who knows the codebase well enough to do actual work (there's at least one other person I'd be comfortable with giving commit access to), and it's clean and documented pretty well for a filesystem.
And the sustainability equation just changed dramatically, thanks to Claude.
I've been using it the past week for a lot of stuff, and I should really write something longer up, but suffice it to say that I'm impressed. It can't do much independently yet, but it's been able to handle a /lot/ of the grunt work - the other night I had it go through open Github issues, fix what it could and take notes on the rest, and I came back to 8 patches for actual bugs, all of them correct, with excellent commit messages. Holy shit, we're living in the future :)
It can't design for shit, it doesn't understand performance implications when writing code (I've noticed this repeatedly); most of how I'm using it is "pair programming". But I'm finally feeling like I'll be able to take a vacation in the near future and still keep up with everything.
Two other people are using it (with heavy review, actively telling it to go back and research topics more) for a big update to the Principles of Operations. Nice.
Basically, the sustainability aspect comes down to writing clean, maintainable, well documented code - and I think I've accomplished that. One holy shit moment the other day was watching Claude navigate /and understand/ btree and journalling code - and making the connection between the way I use assertions and linear typing/dependent typing. All those years spent on that code developing new ways of thinking about and using assertions to make that stuff practical for one person to do... it's paid off.
Beyond that, the real challenges are pushing the boundaries of how introspectable, understandable and transparent complex systems code can be for the end user - and bcachefs is pushing boundaries there. Making a habit of writing pretty printers for absolutely everything means that now our tracing is the best you'll see in software like this, and well integrated with 'bcachefs fs top'. The timestats stuff that I started well over a decade ago - we've now got a new 'bcachefs fs timestats' interface for that, which is already making debugging performance issues dramatically easier than it has been in the past.
This is gamechanging stuff :)