Linux is about to lose a feature – over a personality clash
- Reference: 1755284402
- News link: https://www.theregister.co.uk/2025/08/15/sad_end_of_bcachefs/
- Source link:
As we reported recently, [1]kernel 6.17 is approaching . Linus Torvalds announced the [2]first release candidate on Sunday, August 10. Of course, he is irked about something – that's not unusual – but this time his ire is directed at [3]late RISC-V patches .
However, as [4]Phoronix notes , there is no new bcachefs code in this version so far. Developer Kent Overstreet did submit some [5]minor changes at the end of July, saying:
So, the experimental label is coming off in 6.18.
However, Torvalds has not accepted the code. As we reported [6]earlier in July , it looks like – without any official comment — the stable version of Linux's newest file system, [7]first included in version 6.7 , will not appear in kernel 6.18.
Boxout
As it happens, Canonical has been [8]planning to use kernel 6.17 in the forthcoming Ubuntu 25.10, Questing Quokka, since May. As of this week, Questing is [9]now in feature freeze , and Canonical will probably still [10]use that kernel version even if the final version hasn't been released yet come October. Given the time frame, it's likely that 6.17 will be the last version of 2025, and as such, will probably be the next LTS version of the kernel.
End boxout
Development of the Linux kernel is coordinated through a mailing list known as the [11]LKML . Overstreet's code submission now has a [12]lengthy thread . Overstreet has [13]criticized rival Btrfs , saying:
When brtfs shipped, it did so with clear design issues that have never been adequately resolved.
[…]
As a result, to this day, people don't trust it, and for good reason.
This is true. This vulture has personally experienced serious problems with Brtfs, and has [14]written about them , as well as [15]linking to others' coverage . Red Hat [16]removed it from RHEL in 2017, although [17]Oracle puts it back into its RHELative . These are not baseless accusations, as this recent [18]Hackernews discussion bears out.
This is not a new thing. As we have [19]written before , we remain sure that this is why the bcachefs slogan, in large (but perhaps not very friendly) letters across the top of the [20]project website is: "The COW filesystem for Linux that won't eat your data". It's a dig at Btrfs.
[21]
The issues are real. Such problems need to be discussed. However, what in fact happened was a [22]spirited defence of Btrfs from Meta developer Josef Bacik, concluding with:
Your behavior is unacceptable. This email is unacceptable.
[…]
If you are allowed to continue to be in this community that will be a travesty.
Overstreet responded with a reasoned [23]rebuttal , but that angered ext4 developer Ted T'so:
Kent, you seem to have ignored the primary point of Josef's message, and instead, proceeded to prove exactly what he was pointing out.
[…]
You once again demonstrated exactly why a very large number of kernel developers have decided you are extremely toxic, and have been clamoring that your code be ejected from the kernel. Not because of the code, but because your behavior.
We feel a little context might help here. On the one hand, [24]Ted T'so is one of the most eminent filesystem engineers in the Linux project, and maintains the default [25]ext4 filesystem. On the other hand, T'so's outburst directed at Wedson Filho, the maintainer of Rust for Linux, at a conference last year was closely followed by [26]Filho's resignation due to "nontechnical nonsense" .
Overstreet has [27]sworn not to criticize Btrfs again. Others have [28]backed up his criticisms, and [29]his position . Critics, meanwhile, [30]suggest that he seek psychotherapy, or accuse him of [31]mental illness , or [32]call him a liar . As a whole, it has not been an impressive or dignified debate. The hurt feelings and personal accusations on display are ignoble, to say the least.
[33]
[34]
The whole incident emphasizes the extent to which these ostensibly technical debates are often settled by personality and emotion, rather than by technical excellence.
[35]The plan for Linux after Torvalds has a kernel of truth: There isn't one
[36]Windows 10's demise nears, but Linux is forever
[37]Project Banana ripens into a pre-alpha for KDE Linux, and you can test it
[38]The elusive goal of Unix – or Linux – simplicity
It's not the first time that the kernel team has favored what to external observers seems like the inferior tool. As we previously [39]described , over 20 years ago, the kernel team faced a choice between two rival logical volume management systems: either [40]EVMS , which was [41]backed by IBM , or [42]LVM2 from Sistina Software, which ended up getting [43]acquired by Red Hat .
As the EVMS [44]Wikipedia article notes, "EVMS had more features and better userland tools, but the internals of LVM were more attractive to kernel developers, so in the end LVM won the battle for inclusion." Never mind the poor users, eh? The EVMS team published an extraordinarily graceful [45]message of concession and it disappeared soon afterwards.
It looks likely that Overstreet has upset too many important, influential people, and hurt too many feelings — and as a result, Linux is not going to get a new next-gen copy-on-write filesystem. It's a significant technological loss, and it's all down to people not getting along, rather than the shared desire to create a better OS. ®
Get our [46]Tech Resources
[1] https://www.theregister.com/2025/08/01/geeks_aghast_at_guru_gpu/
[2] https://lwn.net/Articles/1033167/
[3] https://www.theregister.com/2025/08/11/torvalds_blasts_tardy_kernel_dev/
[4] https://www.phoronix.com/news/Linux-6.17-rc1
[5] https://lkml.org/lkml/2025/7/28/873
[6] https://www.theregister.com/2025/07/01/bcachefs_may_get_dropped/
[7] https://www.theregister.com/2024/01/10/linux_kernel_67/
[8] https://discourse.ubuntu.com/t/announcing-6-17-kernel-for-ubuntu-25-10-questing-quokka/61484
[9] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2025-August/001378.html
[10] https://discourse.ubuntu.com/t/linux-6-17-in-ubuntu-25-10-to-be-an-unstable-kernel-at-release/65912
[11] https://lkml.org/
[12] https://lore.kernel.org/lkml/22ib5scviwwa7bqeln22w2xm3dlywc4yuactrddhmsntixnghr@wjmmbpxjvipv/T/#u
[13] https://lore.kernel.org/lkml/3ik3h6hfm4v2y3rtpjshk5y4wlm5n366overw2lp72qk5izizw@k6vxp22uwnwa/
[14] https://www.theregister.com/2022/06/10/review_opensuse_leap_154/
[15] https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/
[16] https://www.theregister.com/2017/08/16/red_hat_banishes_btrfs_from_rhel/
[17] https://www.theregister.com/2022/07/12/oracle_linux_9/
[18] https://news.ycombinator.com/item?id=44508601
[19] https://www.theregister.com/2024/02/28/new_vers_bcachefs_zfs/
[20] https://bcachefs.org/
[21] 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=2aJ-t9CyOs7CxP-czG1FgngAAAM8&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[22] https://lore.kernel.org/lkml/20250809192156.GA1411279@fedora/
[23] https://lore.kernel.org/lkml/2z3wpodivsysxhxmkk452pa4zrwxsu5jk64iqazwdzkh3rmg5y@xxtklrrebip2/
[24] https://thunk.org/tytso/
[25] https://www.kernel.org/doc/html/latest/admin-guide/ext4.html
[26] https://www.theregister.com/2024/09/02/rust_for_linux_maintainer_steps_down/
[27] https://lore.kernel.org/lkml/2e47wkookxa2w6l2hv4qt2776jrjw5lyukul27nqhyqp5fsyq2@5mvbmay7qn2g/
[28] https://lore.kernel.org/lkml/5030625.31r3eYUQgx@woolf/
[29] https://lore.kernel.org/lkml/20250811154826.509952-1-james@egdaemon.com/
[30] https://lore.kernel.org/lkml/55e623db-ff03-4d33-98d1-1042106e83c6@ftml.net/
[31] https://lore.kernel.org/lkml/514556110.413.1754936038265@mail.carlthompson.net/
[32] https://lore.kernel.org/lkml/c1516337-a681-40be-b3f1-4d1e5290cbff@cock.li/
[33] 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=44aJ-t9CyOs7CxP-czG1FgngAAAM8&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[34] 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=33aJ-t9CyOs7CxP-czG1FgngAAAM8&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[35] https://www.theregister.com/2025/08/14/the_plan_for_linux_after/
[36] https://www.theregister.com/2025/01/28/windows_10_demise_linux/
[37] https://www.theregister.com/2025/08/04/kde_linux_prealpha/
[38] https://www.theregister.com/2025/05/27/elusive_goal_of_simplicity/
[39] https://www.theregister.com/2022/03/18/bcachefs/
[40] https://evms.sourceforge.net/
[41] https://www.serverwatch.com/servers/ibm-introduces-new-volume-management-technology-on-linux/
[42] https://sourceware.org/lvm2/
[43] https://www.theregister.com/2003/12/18/red_hat_sweetens_q3/
[44] https://en.wikipedia.org/wiki/Enterprise_Volume_Management_System
[45] https://lwn.net/Articles/14714/
[46] https://whitepapers.theregister.com/
Re: Anecdotally... No To BTRFS Too
Yep I've continued using ext4 because of its stability record. Maybe other filesystems will have better performance but my filesystem performance has increased by so much over the years going from HDD to SSD and now NVMe that even if I could magically get a full order of magnitude better with another filesystem wouldn't be worth it to me if it meant even the smallest risk to my data. I mirror things to avoid data loss from failure of hardware, but if the filesystem itself is the cause of issues mirroring ain't gonna do much good!
Re: Anecdotally... No To BTRFS Too
Been using BTRFS for years (ever since reiserfs was er, deprecated for political reasons) and never had any problems whatsoever with it
EXTx on the other hand, seem to need fscking every now and then to keep it in working order
Re: Anecdotally... No To BTRFS Too
I miss reiserfs.
It was killer!
I guess this is why I'm a FreeBSD fangirl.
zfs as a first class citizen, and none of the toxic drama that seems to be present in Linux circles.
Also, no SystemD.
ZFS is still way ahead of BTRFS in terms of reliability. It is the benchmark to which other file systems aspire. It is not perfect for everything, but what it does it does extremely well.
Everytime I give a look to TrueNAS logs (now built on Debian, unluckily), the kernel complains ZFS taints it... I'd like to know how many kernels at Google, Facebook, Amazon, etc. are "tainted" because they do load proprietary code they will never release to competitors...
I think it's high time the kernel developers just squash this petty CDDL vs GPL license issue that isn't an issue, where they forcibly break ZFS every kernel release, and just adopt OpenZFS. Oracle doesn't care obviously because most of their systems are now GNU/Linux, not Solaris, although Solaris is somewhat maintained still. Or, at least be civil with OpenZFS and let them catch up faster by including them in development cycles so OpenZFS isn't left rotting on the LTS kernels while mainline kernels, the zen kernel, and others get fresh code.
There is parochialism in the Linux kernel world. Not invented here = it's not getting in.
Add me to the list of people who have lost data to BTRFS
Allegedly it is some degree of better now (maybe? I'm not playing guinea pig again), but it was rushed into production use way too quickly which certainly brings into question the judgment of the people deciding which filesystems to include in the kernel.
Re: Add me to the list of people who have lost data to BTRFS
I guess it depends on what you want to do with it. I've been running btrfs on Debian for at least the last two releases without any problems. However, I only use a single SSD and I don't use btrfs for RAID, subvolumes or anything advanced. I use it purely for snapshots so that I can ensure the backups taken by my URBackup server are consistent.
Re: Add me to the list of people who have lost data to BTRFS
Why do people like you even write these comments? What does it bring to the discussion?
I didn't say it happens to everyone. Nobody is claiming it. Clearly it works well for many people. If it works for you, that's great and I'm happy for you. If it works at Meta, who has (comparatively) infinity dollars for systems validation before putting hardware and software into production, that's great and I'm happy for them. However, it has also failed for many people - apparently mostly in multiple-disk configurations where significantly more data is at risk.
Re: Add me to the list of people who have lost data to BTRFS
Why does the OP write the comment they did? "Well sure, there have been problem reports, no duh"
Together, they can help establish a general "safe" area of usage. Works fine for single disks, with snapshots (that surprised me), but not RAID (raid5 still has a random data-loss during normal usage, as of.. 2020?), and not "advanced usage".
I took an image of an ext4 volume with btrfs convert, and two months later I had to back up all data and restore from backup (with some loss) - initially the image had some unaligned pieces and I found later the "initial" image had some out-of-bounds reads when doing btrfs check (which you're never supposed to have to do), eventually leading to data loss.
Feel free to contribute your own experience. Does it work? does it not? Are you just going to say "yes" or "no" without any detail?
An unfortunate turn of events
I've seen that Kent has a quite abrasive style and forceful personality. It can be difficult to get along with people who are like that. Sometimes though, you have to.
It's sad to see something which would undeniably be a positive option excluded from the kernel for seemingly the wrong reasons. Such is the nature of groups.
Re: An unfortunate turn of events
The problem is not just for this one instance of the code being submitted and normal procedures/etiquette not being followed, it is the future dependency for many user's data integrity on a major maintainer who has issues in cooperating with the majority.
Let us not mention ReiserFS in this discussion...
Re: An unfortunate turn of events
ReiserFS?
"After all, a murder is only an extroverted suicide."
There are certain things you don't say about or to others
Making any kind of claims of mental illness -- especially in anger or defensively -- is one of those things.
You don't really know them through just an exchange of emails. You don't know what's going on in their head, their personal life, et cetera. Claiming they are, essentially, sick -- even abnormal -- crosses a line.
I am not a doctor but we all have some experience with ourselves or others. I know I have some low-level anxiety/anger issues and have been through bouts of depression. It takes a gentle hand from a close trusted source to help someone into and along a path to mental wellness. Angry accusations aren't going to help that and might trigger even worse mental state and behavior.
Happy weekend, everyone. This ---> for those who choose to (and aren't dealing with addictions and the like; apologies to those who are).
Re: There are certain things you don't say about or to others
Welll said.
Linux: Life without a marketing department.(NT}
t.
Not due to a clash of personalities...
The issue is that Kent Overstreet is seemingly unwilling to follow the standard rules for the kernel development. New features can be added during the merge window, but not during the release candidate stages that follow.
If there was a need to provide a fix between the merge windows for a user having serious issues, that could easily have been provided to the user as a patchset, and then included in the next merge window.
Re: Not due to a clash of personalities...
Linux seems to have announced the [1]merge window for 6.17 late in July and Kent Overstreet's pull request as linked in the article is dated Mon, 28 Jul 2025 11:14:33 -0400.
This article is not about Palmer Dabbelt and his late RISC-V patches (the article has a link to the el reg coverage of that as well) but talks about a separate issue.
[1] https://lwn.net/ml/all/CAHk-=wh0kuQE+tWMEPJqCR48F4Tip2EeYQU-mi+2Fx_Oa1Ehbw@mail.gmail.com/
Re: Not due to a clash of personalities...
Exactly. He wants to issue important features faster than the kernel development process allows, so it's a good thing for it to step out of tree for a while until its development stabilises and he doesn't have to rush out features *after* the last minute.
Due to personality clashes
>> It's a significant technological loss
A proven to be unreliable file system is available to slurp all your data. It won't go wrong, until it does. And then you should have had backups.
Justice for bcachefs!
This is such a shame. Bcachefs is the most important filesystem development in linux in the last 2 decades.
Some of the abuse directed to Overstreet on public mailing lists has been shocking. The kernel developers responsible should be ashamed.
(FWIW, I also lost a btrfs filesystem which imploded, not after a power loss, but after running out of disk space.)
Re: Justice for bcachefs!
The irony is that if the BTRFS developers were as good at writing code as they are at holding grudges, none of this discussion would be happening.
I'm not a LKML geek, but reading this thread suggests to me that there's a lot of ivory-tower mentality in FS-land ("it works well in theory and in my lab, if it doesn't work for the rest of the world then it's the rest of the world that's wrong") and that does not bode well for the future of the operating system.
Re: Justice for bcachefs!
Not being a filesystem expert and being just a person who wishes to compute, a lot (okay, almost all ) of this discussion is lost on me.
Anyone want to educate me on what bcachefs brings to the party that, say, ext4 doesn't?
I've been running ext4 fileystems on my machines for ages and never had the slightest burp (. . . checks backups in fear of incurring the the wrath of the deities of overconfidence. . .) or failure on a system that's been running 24/7 for at least four years.
Re: Justice for bcachefs!
I'm there with you. I understood from the article that they're both filesystems, and bcachefs is substantially less stable than btrfs (which, for a filesystem, is an excellent reason to nope right out of town), but why use one of these instead of another filesystem? Saying no to NTFS I understand (being proprietary is one good reason), but why not ext4, XFS, ZFS...?
(I really am honestly asking, knowing very little about the different filesystems.)
Oh I don't want to feel bad
I didn't see anything offensive from Overstreet in the article. If the btrfs dev asked for specifics, I'd think he would get them. Arnold says it best 0:09 - 1:37 https://www.youtube.com/watch?v=pwqxdCGCDE8
Anecdotally... No To BTRFS Too
I have run Fedora as my main OS for ages, and when i implemented an SSD the default installer installed BTRFS. I have had multiple crashes which recovered and some did not, due to BTRFS. After the first non bootable crash i was able to recover the data and installed again. After the second i could not access the data. So i built a new machine and ensured EXT4 was the file system used.
I do check the Fedora forums to see whether BTRFS has caused problems, and there are sometimes reference to it, but many people are not aware that BTRFS is the issue, and just simply state the PC crashed.
It would be good for Fedora to default back to EXT4 for their installer as changing from BTRFS to EXT4 means that for the average person, they will have difficulty.