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.
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.