New Linux Kernel Drama: Torvalds Drops Bcachefs Support After Clash (itsfoss.com) 20
Bcachefs "pitches itself as a filesystem that 'doesn't eat your data'," writes the open source/Linux blog It's FOSS. Although it was last October that Bcachefs developer Kent Overstreet was restricted from participating in the Linux 6.13 kernel development cycle (after ending a mailing list post with "Get your head examined. And get the fuck out of here with this shit.")
And now with the upcoming Linux kernel 6.17 release, Linus Torvalds has decided to drop Bcachefs support, they report, "owing to growing tensions" with Overstreet: The decision follows a series of disagreements over how fixes and changes for it were submitted during the 6.16 release cycle... Kent filed a pull request to add a new feature called "journal-rewind". It was meant to improve bcachefs repair functionality, but it landed during the release candidate (RC) phase, a time usually reserved for bug fixes, not new features, as Linus pointed out. [Adding "I remain steadfastly convinced that anybody who uses bcachefs is expecting it to be experimental. They had better."]
Theodore Ts'o, a long-time kernel developer and maintainer of ext4, also chimed in, saying that Kent's approach risks introducing regressions, especially when changes affect sensitive parts of a filesystem like journaling. He reminded Kent that the rules around the merge window have been a long-standing consensus in the kernel community, and it's Linus's job to enforce them. After some more back and forth, Kent pushed back, arguing that the rules around the merge window aren't absolute and should allow for flexibility, even more so when user data is at stake. He then went ahead and resubmitted the patch, citing instances from XFS and Btrfs where similar fixes made it into the kernel during RCs. Linus merged it into his tree, but ultimately decided to drop Bcachefs entirely in the 6.17 merge window.
To which Kent responded by clarifying that he wasn't trying to shut Linus out of Bcachefs' decisions, stressing that he values Linus's input...
This of course follows the great Torvalds-Overstreet "filesystem people never learn" throwdown back in April.
And now with the upcoming Linux kernel 6.17 release, Linus Torvalds has decided to drop Bcachefs support, they report, "owing to growing tensions" with Overstreet: The decision follows a series of disagreements over how fixes and changes for it were submitted during the 6.16 release cycle... Kent filed a pull request to add a new feature called "journal-rewind". It was meant to improve bcachefs repair functionality, but it landed during the release candidate (RC) phase, a time usually reserved for bug fixes, not new features, as Linus pointed out. [Adding "I remain steadfastly convinced that anybody who uses bcachefs is expecting it to be experimental. They had better."]
Theodore Ts'o, a long-time kernel developer and maintainer of ext4, also chimed in, saying that Kent's approach risks introducing regressions, especially when changes affect sensitive parts of a filesystem like journaling. He reminded Kent that the rules around the merge window have been a long-standing consensus in the kernel community, and it's Linus's job to enforce them. After some more back and forth, Kent pushed back, arguing that the rules around the merge window aren't absolute and should allow for flexibility, even more so when user data is at stake. He then went ahead and resubmitted the patch, citing instances from XFS and Btrfs where similar fixes made it into the kernel during RCs. Linus merged it into his tree, but ultimately decided to drop Bcachefs entirely in the 6.17 merge window.
To which Kent responded by clarifying that he wasn't trying to shut Linus out of Bcachefs' decisions, stressing that he values Linus's input...
This of course follows the great Torvalds-Overstreet "filesystem people never learn" throwdown back in April.
Kent by name, K*unt by nature (Score:1)
Linus' kernel, Linus' rules.
Don't break shit. pretty simple.
All the drama (Score:1)
Re: (Score:3, Funny)
Is always with filesystem developers.
*reiserfs enters the chat*
Re: (Score:2)
Re: (Score:1)
It was almost comical watching people here defend that guy. Some choice arguments.
He's just weird and kind of autistic.
His mail order bride is missing and he seems pretty unconcerned.
The guy just happened to buy books about crime and forensics right after she went missing? Not suspicious to me!
Look who here hasn't removed the back seat from their car and then forgot where it went?
Re:All the drama (Score:5, Informative)
Re: (Score:2)
However, most driver programmers don't know what they are doing. That isn't going to change in the term. Rust allows them to write drivers without writing memory leaks or buffer overruns. Net win.
Re: nope, also rust people (Score:4, Insightful)
Whenever I throw this in a discussion, it usually goes in the "Good programmers do not make these mistakes" direction. But... I have worked with good and bad programmers. They all make mistakes. The bad programmer apologizes and fixes it. The good one plays the blame game and even may throw in a tantrum.
I love and hate C/C++. Love it for speed, hate it whenever it points out I am not a God but a miserable error making human.
Re: (Score:2)
The example that I remember was "if (a = 5) ". It compiles and runs. But it is a typo that is not flagged
It gets flagged as a warning by most compilers. In GCC, don't disable -Wno-parentheses
Re: nope, also rust people (Score:2)
Also, Yoda notation is a thing.
How to Win Friends and Influence People (Score:5, Informative)
"I positively enjoy working with you - when you're not being a dick, but you can be genuinely impossible sometimes."
- Overstreet replying to Linus threatening not to merge any of his future code.
If that's what young people call an apology, no wonder Torvalds is sick of dealing with him. Yet the media will twist this as 'evil Linus'.
Re:How to Win Friends and Influence People (Score:4, Insightful)
All Overstreet needs to do is figure out how a merge window works. He doesn't need to write a perfect apology.
Re: (Score:1)
All Overstreet needs to do is...
All Overstreet needs to is continue development as he wishes. There is no fundamental reason bcachefs must be included in Linus's mainline kernel. The kernel has loadable modules. This work can simply be a loadable module. There are tools to make this next to transparent to an end user, up to and including as a root file system. ZFS On Linux has existed this way for 15 years now. There are entire commercial empires built around it, and it has never, at any point, been in the Linux mainline code base.
Re: (Score:3)
2025 sure is weird:
- Linux is the most popular OS kernel in the world.
- Windows supports running Linux natively on the OS.
- Linus is the most level headed voice in the room.
Somehow the last one was the least likely to be on my bingo card.
Great loss; could have been worse (Score:2)
This is a great loss for all open source filesystem users. What could Bcachefs have become? However what would have been a truly great loss is if Overstreet had learned to work well with others and then we lost it. Bcachefs was not yet really on the path to future adoption because it had neither broad developer support nor corporate backing. It was one guy's pet project, no matter how technologically promising it was.
Re: (Score:2)
Out of curiosity, what was the technological promising thing about it?
I only see the constant last-minute fixes it seems to need and that user space tooling is dropped from Debian for being unmaintainable, which tells me that - regardless what technological wonder it may be - it is certainly not a filesystem I would use.
Re: (Score:2)
Who the fuck is Linus? (Score:1)
He reminded Kent that the rules around the merge window have been a long-standing consensus in the kernel community, and it's Linus's job to enforce them.
Quick question for all you Linux lickers out there; who the fuck is Linus and why is one guys job “to enforce them”?
Yes, old heads. I want you to pretend for a moment someone wrote this and then tell me how serious people should take Linux:
He reminded Redmond that the rules around the patch process have been a long-standing consensus in the Microsoft community, and it's Bill’s job to enforce them.
I hope Linux actually has a succession plan for when The Almighty Linus dies. Somehow I don’t think canonization is gonna help the merge schedule.