Linus Torvalds hints Bcachefs may get dropped from the Linux kernel
- Reference: 1751368507
- News link: https://www.theregister.co.uk/2025/07/01/bcachefs_may_get_dropped/
- Source link:
The latest installment in the continuing drama over the next-gen bcachefs filesystem is that Torvalds [1]accepted the code , for now, but added a sobering warning:
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."
The Linux kernel is the world's biggest FOSS project, thanks in part to the strong control exerted by Torvalds himself. There's a process, although it's not something that is formally documented and described. Like Linux itself, this process has evolved over time. Each time a new point-release of the kernel comes out, Torvalds starts work on the next one. He opens what's termed a merge window , as The Register [2]described a few years ago .
During that time window, developers submit new code for inclusion. Then follows a series of work-in-progress test releases, with rc for "release candidate" on the end of the version number: right now, we're on [3]6.16-rc4 . Code submissions – in the terminology of the Git revision-control system, "pull requests" – continue during that time, but they are meant to be bug fixes and only bug fixes.
This time around, bcachefs maintainer Kent Overstreet submitted a PR that included some new functionality. That's a big no-no: the RC phase is for fixing stuff sent in during the merge window. Torvalds [4]was not happy , but Overstreet, as he tends to, didn't back down but rather [5]defended the change .
[6]
Overstreet has been rebuked before; indeed, he was [7]barred from contributing to kernel 6.13 in November 2024. Linux Weekly News [8]summarizes what's happening and we link to that because Overstreet himself appears to be defending his moves at some length in the article comments.
[9]
[10]
The bcachefs saga has been going on for a decade now; The Reg [11]first reported on it in August 2015. Now, after finally being [12]included in kernel 6.7 in January 2024, it looks possible that it could get kicked out again.
[13]OpenBSD 7.7 released with updated hardware support, 9Front ships second update of 2025
[14]SystemRescue 12 lands with added bcachefs support
[15]Public developer spats put bcachefs at risk in Linux
[16]Linus Torvalds declares war on the passive voice
If this happens, it does not spell the end of the [17]bcachefs project . In fact, there are several potential ways forward, as discussed in the LWN comments. It could continue as an external development. In order to use it, there are multiple possibilities. People wanting to try it could build their own custom, modified kernels.
In another scenario, a version could be built that used the [18]FUSE subsystem , which allows filesystem code to run outside of the kernel itself. That works and it's been optimized in recent years, but it's substantially slower than in-kernel code. Alternatively, the code could be built on demand when the kernel is updated: there's a standard tool for this, [19]called DKMS , which is how people running the Nvidia display drivers get them.
Or, potentially, the dispute between these two genius-level personalities could get resolved… but no amount of code will help there. ®
Get our [20]Tech Resources
[1] https://lwn.net/ml/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/
[2] https://www.theregister.com/2022/10/17/linux_6_1_rc1/
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v6.16-rc4
[4] https://lore.kernel.org/lkml/CAHk-=wi2ae794_MyuW1XJAR64RDkDLUsRHvSemuWAkO6T45=YA@mail.gmail.com/
[5] https://lore.kernel.org/lkml/lyvczhllyn5ove3ibecnacu323yv4sm5snpiwrddw7tyjxo55z@6xea7oo5yqkn/
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aGQGFnGpnDfy2IxKkaUBlgAAAA0&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://www.theregister.com/2024/11/22/bcachefs_linux/
[8] https://lwn.net/Articles/1027289/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aGQGFnGpnDfy2IxKkaUBlgAAAA0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aGQGFnGpnDfy2IxKkaUBlgAAAA0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2015/08/24/does_linux_need_a_new_file_system_exgoogle_engineer_thinks_so/
[12] https://www.theregister.com/2024/01/10/linux_kernel_67/
[13] https://www.theregister.com/2025/04/29/openbsd_77_is_out/
[14] https://www.theregister.com/2025/03/20/systemrescue_12_bcachefs/
[15] https://www.theregister.com/2024/11/22/bcachefs_linux/
[16] https://www.theregister.com/2024/10/08/linus_torvalds_grammar_complaint/
[17] https://bcachefs.org/
[18] https://tleb.fr/linux/filesystems/fuse.html
[19] https://github.com/dell/dkms
[20] https://whitepapers.theregister.com/
That's typical of the Judean People's Front, you're all up to this sort of thing.
Can't wait for the People's Front of Judea to wipe the floor with you all!
Splitter
The process exists to make the publication of a new kernel version frictionless and reliable, and it seems the submitter thinks they know better, so I'm not surprised to see a rebuke -- it's Torvald's sign off and reputation that's on the line.
Reading the comments on the LWN article
including and especially those from Kent Overstreet I would conclude he has already resigned himself to the out of tree, DKMS route.
What I hadn't appreciated was that Kent is pretty much the sole developer for bcachefs which is a concern even if a wayward bus isn't on the horizon - just poor life decisions a là Hans Reiser, can torpedo a file system project.
To be charitable I can see that Linus has particular priorities in respect of the kernel generally and file systems in particular while Kent has similar file system priorities perhaps in a different order which cannot consistently map on to the development process.
ZFS while an out of tree file system it is really not a good example as its history as a proprietary file system and continued FOSS team development on three platforms makes ZFS unique.
ZFS is available as a kernel kABI (odd term, kBI surely) tracking package for the *EL family from at least one repository (as are NVIDIA drivers.)
I imagine if bcachefs were maintained as a DKMS and there was a clear need or demand then these repositories might also package it in the same way.
Re: Reading the comments on the LWN article
He’s still arguing black is white on the LWN article though. I spent ages yesterday reading it all. It’s fascinating how out of touch he is with reality to be honest.
Re: Reading the comments on the LWN article
Sounds like the sort of person I'd walk across the street for... to keep away from!
We do not release on Friday
Why we don't release on Friday? It's a small change, it won't break anything!
Because: He who burns his tongue from the soup will blow on yogurt.
It's as simple as that.
Attitude…
The main issue here seems to be Overstreet’s attitude, arrogance and sense of entitlement. He also comes across in some of his replies as a bit of an obsessive nutcase.
He believes he knows better than Linus and the other maintainers and doesn’t have to play by the rules that other maintainers have to. He then argues black is white even though he’s quite clearly wrong and it’s him who is the problem, but he won’t accept that.
People have clashes on LKML all the time, most of them begrudgingly accept the status quo and abide by it, but Overstreet is incapable of doing that and it just results in unnecessary conflict which he isn’t going to win.
Getting bcachefs kicked out of the kernel just ensures that less people will use it and Overstreet won’t have any influence to push for changes in the way that the kernel merges code.
If only he’d shut up, done as he was told, stopped being an argumentative idiot, the respect would eventually have been earned and he would be listened to, rather than being told to get stuffed. He’s done this to himself.
"The main issue here seems to be Overstreet’s attitude, arrogance and sense of entitlement. He also comes across in some of his replies as a bit of an obsessive nutcase."
Ah, he must post here occasionally, probably as an AC.
What I don't understand - and would love someone to enlighten me (!) - is why there is this massive thing around drivers being included in the kernel or not. Especially it seems to filesystems.
Why can Linux not have some mechanism like Windows where manufacturers or developers can distribute their own device drivers and users load the drivers they like.
Sure, there are problems with sketchy or unreliable drivers but that's on the developers and users to decide if they want to use them or not, rather than Linus as an arbitary gatekeeper of what is allowed.
Then the kernel could be much smaller and not need to include lots of drivers a lot of people won't need.
I'm fairly sure that's how DKMS drivers work. Linux has something called Loadable Kernel Modules (LKMs) that are pretty much what you describe. You do generally need to build them from source against your currently running kernel's headers though I believe.
Well, I'm with the Judean People's Front, so down with the People's Front of Judea!