The developer of bcachefs, Kent Overstreet has repeatedly failed to abide by the expectations of kernel release schedules, particularly the rc (release candidate) stage, which is supposed to freeze new features until next release.
Kent has open-air arguments with Linus Torvalds about not being able to develop the way he wants to, Linus Torvalds does not like wasting time discussing it with Kent.
IMO, Kent created this situation himself. He’ll be happier developing outside upstream anyway.
It should be noted that while some folks have commented that bcachefs was not ready for upstream, several kernel devs have a lot of respect for the technical quality of Kent’s work, so I think the argument of whether bcachefs is good or not good is separate from Kent’s behaviour as a kernel contributor.
It was nowhere close to be mature enough to be in the kernel. The developer is nowhere close to be mature enough to be involved in the kernel. It’s better for everybody if it is developed separately and maybe integrated again at a later stage when the file system and tooling are considered stable and changes are smaller and less sensitive. CacheFS being in the kernel might mislead people to rely on a filesystem that is still experimental and under heavy development. Personally I am looking forward to see it mature because I’d love to run it on my file storage home server when it is stable enough.
That the developer himself finds it absolutely necessary to push new code outside the window for upcoming versions of the kernel is a pretty good indication.
That is a personality issue, not a code emergency.
There were two dozen patches submitted for 6.17 that were never merged. What has the fall-out been? Where are all the stories about data loss? I am sure they would hit the front page.
The file system can improve but it is already fine.
That is a personality issue, not a code emergency.
True, but it is an indication that the developer cannot follow a common rules. Simply Torvalds was tired of how he behaved.
There were two dozen patches submitted for 6.17 that were never merged. What has the fall-out been? Where are all the stories about data loss? I am sure they would hit the front page.
And so ? A patch can be submitted but never merged, for whatever reason. Problem is: these two dozen patches were submitted during the -RC cycle ?
The file system can improve but it is already fine.
Good. Now it it the developer that need to improve his attitude to work in teams.
The fallout for people knowingly risking their data beta testing a filesystem that is still in experimental and some users running into issues and possibly corruption?
There are no stories because it is not a story when a test environment for finding bugs fails and the bugs get fixed. Nobody with data they can not lose are putting it on bcachefs because why would they.
Thanks for running a test environment though. Please take backups of anything important, just in case.
Yes I’m asking for the reason why you think this development is good. It seemed to me like it could have worked out if they talked it out and could have added something of value to the OS
There’s no reason to be rude and insulting. It doesn’t make the other person look lazy; it just makes you look bad, especially when you end up being wrong because you didn’t do any research either. The article is garbage. It’s obviously written by someone who wants to talk about why they don’t like bcachefs, which would be fine, but they make it look like that’s why Linus wanted to remove bcachefs, which is a blatant lie.
Despite this, it has become clear that BcacheFS is rather unstable, with frequent and extensive patches being submitted to the point where [Linus Torvalds] in August of last year pushed back against it, as well as expressing regret for merging BcacheFS into mainline Linux.
But if we click on the article’s own source in the quote we see the message (emphasis mine):
Yeah, no, enough is enough. The last pull was already big.
This is too big, it touches non-bcachefs stuff, and it’s not even
remotely some kind of regression.
At some point “fix something” just turns into development, and this is
that point.
Nobody sane uses bcachefs and expects it to be stable, so every single
user is an experimental site.
The bcachefs patches have become these kinds of "lots of development
during the release cycles rather than before it", to the point where
I’m starting to regret merging bcachefs.
If bcachefs can’t work sanely within the normal upstream kernel
release schedule, maybe it shouldn’t be in the normal upstream
kernel.
This is getting beyond ridiculous.
Stability has absolutely nothing to do with it. On the contrary, bcachefs is explicitly expected to be unstable. The entire thing is about the developer, Kent Overstreet, refusing to follow the linux development schedule and pushing features during a period where strictly bug fixes are allowed. This point is reiterated in the rest of the thread if anyone is having doubts about whether it is stated clearly enough in the above message alone.
I’ve heard about this and wanted to hear your opinion on it because you seemed to have gotten to another conclusion than I have. But it seems that you’re not interested in discussing so I’m no longer interested
Good 👍
Why?
The developer of bcachefs, Kent Overstreet has repeatedly failed to abide by the expectations of kernel release schedules, particularly the rc (release candidate) stage, which is supposed to freeze new features until next release.
Kent has open-air arguments with Linus Torvalds about not being able to develop the way he wants to, Linus Torvalds does not like wasting time discussing it with Kent.
IMO, Kent created this situation himself. He’ll be happier developing outside upstream anyway.
It should be noted that while some folks have commented that bcachefs was not ready for upstream, several kernel devs have a lot of respect for the technical quality of Kent’s work, so I think the argument of whether bcachefs is good or not good is separate from Kent’s behaviour as a kernel contributor.
Additionally, Kent got most of his kernel changes needed for bcachefs merged already, so a dkms should be easier to manage now.
It was nowhere close to be mature enough to be in the kernel. The developer is nowhere close to be mature enough to be involved in the kernel. It’s better for everybody if it is developed separately and maybe integrated again at a later stage when the file system and tooling are considered stable and changes are smaller and less sensitive. CacheFS being in the kernel might mislead people to rely on a filesystem that is still experimental and under heavy development. Personally I am looking forward to see it mature because I’d love to run it on my file storage home server when it is stable enough.
I have been relying on the filesystem. It is excellent. It is mature enough.
Sadly, the lead dev for bcachefs is not mature enough.
I agree, on both statements.
It is easily stable enough for experimental use.
what independently verifiable condition(s) will satisfy these requirements?
That the developer himself finds it absolutely necessary to push new code outside the window for upcoming versions of the kernel is a pretty good indication.
That is a personality issue, not a code emergency.
There were two dozen patches submitted for 6.17 that were never merged. What has the fall-out been? Where are all the stories about data loss? I am sure they would hit the front page.
The file system can improve but it is already fine.
True, but it is an indication that the developer cannot follow a common rules. Simply Torvalds was tired of how he behaved.
And so ? A patch can be submitted but never merged, for whatever reason. Problem is: these two dozen patches were submitted during the -RC cycle ?
Good. Now it it the developer that need to improve his attitude to work in teams.
The fallout for people knowingly risking their data beta testing a filesystem that is still in experimental and some users running into issues and possibly corruption?
There are no stories because it is not a story when a test environment for finding bugs fails and the bugs get fixed. Nobody with data they can not lose are putting it on bcachefs because why would they.
Thanks for running a test environment though. Please take backups of anything important, just in case.
They want you to use Oracle ZFS instead, they have a lot of money riding on this.
Seriously?
Not all of us know what this is. Can you expand on your thoughts?
https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesystem-stability-controversy/
https://xkcd.com/1053
Yes I’m asking for the reason why you think this development is good. It seemed to me like it could have worked out if they talked it out and could have added something of value to the OS
Very easy to search, but you’re lazy so:https://hackaday.com/2025/06/10/the-ongoing-bcachefs-filesystem-stability-controversy/
There’s no reason to be rude and insulting. It doesn’t make the other person look lazy; it just makes you look bad, especially when you end up being wrong because you didn’t do any research either. The article is garbage. It’s obviously written by someone who wants to talk about why they don’t like bcachefs, which would be fine, but they make it look like that’s why Linus wanted to remove bcachefs, which is a blatant lie.
But if we click on the article’s own source in the quote we see the message (emphasis mine):
Stability has absolutely nothing to do with it. On the contrary, bcachefs is explicitly expected to be unstable. The entire thing is about the developer, Kent Overstreet, refusing to follow the linux development schedule and pushing features during a period where strictly bug fixes are allowed. This point is reiterated in the rest of the thread if anyone is having doubts about whether it is stated clearly enough in the above message alone.
Ohhhh nooooo 🙀
I’ve heard about this and wanted to hear your opinion on it because you seemed to have gotten to another conclusion than I have. But it seems that you’re not interested in discussing so I’m no longer interested