> ## Content Index > Fetch the complete content index at: https://itsfoss.com/llms.txt > Use this file to discover other available public pages before exploring further. # New Linux Kernel Drama: Torvalds Drops Bcachefs Support After Clash - URL: https://itsfoss.com/news/linux-kernel-bcachefs-drop/ - Published: 2025-06-27T14:02:34.000Z - Updated: 2025-06-27T14:02:34.000Z - Description: Things have taken a bad turn for Bcachefs as Linux supremo Linus Torvalds is not happy with their objections. - Author: Sourav Rudra - Tags: Linux, News, #Import 2025-11-08 21:15 The process of [Linux kernel](https://kernel.org/?ref=itsfoss.com) development is prone to arguments, strong opinions, and the occasional dramatic standoff. Despite that, development has progressed steadily over the decades, driven by a diverse community of contributors who are as passionate as they are principled. And every once in a while, one of these internal debates spills into public view. This time, it's [Bcachefs](https://bcachefs.org/?ref=news.itsfoss.com), the COW filesystem that pitches itself as a filesystem that "*doesn't eat your data*". ## No More Bcachefs in Linux? ![linus torvalds is seen saying the following: i have pulled this, but also as per that discussion, i think we'll be parting ways in the 6.17 merge window. You made it very clear that I can't even question any bug-fixes and I should just pull anything and everything. honestly, at that point, i don't really feel comfortable being involved at all, and the only thing we both seemed to really fundamentally agree on in that discussion was "we're done" linus](https://itsfoss.com/content/images/2025/06/linus-torvalds-is-done-with-bcachefs.png) **Linus is not happy.* With the upcoming Linux kernel 6.17 release, **Linus Torvalds has decided to drop Bcachefs support**, owing to growing tensions between himself and Bcachefs maintainer [Kent Overstreet](https://www.patreon.com/bcachefs?ref=itsfoss.com). The decision follows a series of disagreements over how fixes and changes for it were submitted during the 6.16 release cycle. Friction between them isn’t new. Late last year, Kent [was called out](https://itsfoss.com/linux-kernel-bcachefs/) for an offensive reply to Linux memory management (MM) developer, Michal Hocko, and this just seems like a conclusion to everything that’s happened since. You see, recently, Kent filed a [pull request](https://lore.kernel.org/all/4xkggoquxqprvphz2hwnir7nnuygeybf2xzpr5a4qtj4cko6fk@dlrov4usdlzm/?ref=itsfoss.com) 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](https://lore.kernel.org/all/CAHk-=wi2ae794%5FMyuW1XJAR64RDkDLUsRHvSemuWAkO6T45=YA@mail.gmail.com/?ref=itsfoss.com). ![](https://itsfoss.com/content/images/2025/06/kent-overstreet-bcachefs-journal-rewind-change-1.png) ![](https://itsfoss.com/content/images/2025/06/linus-torvalds-reprimands-kent-overstreet-1.png) [Theodore Ts'o](https://thunk.org/tytso/?ref=itsfoss.com), a long-time kernel developer and maintainer of ext4, [also chimed in](https://lore.kernel.org/all/20250620124346.GB3571269@mit.edu/?ref=itsfoss.com), 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](https://lore.kernel.org/all/bwhemajjrh7hao5nzs5t2jwcgit6bwyw42ycjbdi5nobjgyj7n@4nscl4fp6cjo/?ref=itsfoss.com), 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](https://lore.kernel.org/all/ahdf2izzsmggnhlqlojsnqaedlfbhomrxrtwd2accir365aqtt@6q52cm56jmuf/?ref=itsfoss.com), citing instances from XFS and Btrfs where similar fixes made it into the kernel during RCs. Linus [merged](https://lore.kernel.org/all/175099518936.1417711.15496967287571518216.pr-tracker-bot@kernel.org/?ref=itsfoss.com) it into his tree, but [ultimately decided](https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/?ref=itsfoss.com) to drop Bcachefs entirely in the 6.17 merge window. To which Kent [responded](https://lore.kernel.org/all/xl2fyyjk4kjcszcgypirhoyflxojzeyxkzoevvxsmo26mklq7i@jw2ou76lh2py/?ref=itsfoss.com) by clarifying that he wasn’t trying to shut Linus out of Bcachefs' decisions, stressing that he values Linus’s input, and saying: > I don't want to be in that position. > > I'm just not going to have any sense of humour where user data integrity is concerned or making sure users have the bugfixes they need. > > Like I said - all I've been wanting is for you to tone it down and stop > holding pull requests over my head as THE place to have that discussion. > > You have genuinely good ideas, and you're bloody sharp. It is FUN getting shit done with you when we're not battling. > > But you have to understand the constraints people are under. Not just > myself. Currently, the matter seems to have reached its conclusion. But given the ever-changing nature of kernel development, **there's always a chance that perspectives could shift**. That said, I wouldn't hold my breath. You can follow the full story by checking the [Linux kernel 6.16-rc3](https://lore.kernel.org/all/4xkggoquxqprvphz2hwnir7nnuygeybf2xzpr5a4qtj4cko6fk@dlrov4usdlzm/t.atom?ref=itsfoss.com) and [Linux kernel 6.16-rc4](https://lore.kernel.org/all/ahdf2izzsmggnhlqlojsnqaedlfbhomrxrtwd2accir365aqtt@6q52cm56jmuf/t.atom?ref=itsfoss.com) mailing list threads related to Bcachefs. **Via:** [Thorsten Leemhuis](https://hachyderm.io/@kernellogger/114753292540598749?ref=itsfoss.com)