Linus Torvalds Marks Bcachefs as Now 'Externally Maintained' (phoronix.com) 48
Linus Torvalds updated the kernel's MAINTAINERS file to mark Bcachefs as "externally maintained," signaling he won't accept new Bcachefs pull requests for now. "MAINTAINERS: mark bcachefs externally maintained," wrote Torvalds with the patch. "As per many long discussion threads, public and private."
"The Bcachefs code is still present in the mainline Linux kernel likely to prevent users from having any immediate fall-out in Bcachefs file-systems they may already be using, but it doesn't look like Linus Torvalds will be honoring any new Bcachefs pull requests in the near future," adds Phoronix's Michael Larabel.
"The Bcachefs code is still present in the mainline Linux kernel likely to prevent users from having any immediate fall-out in Bcachefs file-systems they may already be using, but it doesn't look like Linus Torvalds will be honoring any new Bcachefs pull requests in the near future," adds Phoronix's Michael Larabel.
Sad (Score:3)
was the most promising Linux filesystem. To be able to use a SSD as a cache for hard drive (RAID) array is a very useful use case. And block-level caching will never be as optimal as filesystem-level caching. De-fragmenting the filesystem shouldn't invalid the cache.
Re: (Score:3)
You can use zfs, just that you need to install it separately. I use zfs on a lot of stuff, but have not tired bcachefs, as it is still "experimental" IIRC, so I do not know what it offers better than zfs.
Re: (Score:2)
Yeah, I meant it that I need to install it, it does not come built into the kernel like ext4 or xfs.
Re: (Score:3)
ZFS is awesome. However, in the RHEL universe, it isn't supported. Yes, it will work, but when dealing with production, what works and is supported by the vendor are two different things. Even though Fedora has btrfs, Red Hat Linux doesn't have a single checksumming FS as a supported option. The only way to do that is to use a stack of block utilities, like dm-integrity, md-raid, and such to add that onto the lower layers, then throw XFS or ext4 on top.
Having bcachefs would have been a nice alternative,
Re: (Score:2)
However, in the RHEL universe, it isn't supported. Yes, it will work, but when dealing with production, what works and is supported by the vendor are two different things.
That's kind of Redhat's jam or it's user's jam, or the whole sort of general mishmash of them. If you are very conservative[*] and want vendor support, you pay for that. I find it surprising there isn't an out of the box tool provided by Redhat, but in some sense, this is all a bit new (very loosely speaking) to the world of Linux, and aga
Re: (Score:2)
bcachefs uses a license which allows it to be officially integrated into the kernel, it could have become a better alternative to btrfs in many things it already is!
Re: Sad (Score:3, Interesting)
Well, less sad and more better than expected. Given the behavior of the bcache maintainer/creator, i fully expected it to be torn out entirely. It's experimental after all, so removing it was totally on the table.
This is good news. (Score:5, Funny)
Now that this Bcache nonsense is behind us, Linus can concentrate fully on making NTFS the main file system for Linux.
Re: (Score:2)
I heard FAT12 had it beat for raw performance.
Re: (Score:2)
But is FAT12 webscale?
Re: (Score:2)
The FAT8 filesystem is probably even better due to its sectors being physical track-aligned and the system area being located in a track close to the middle of the disk.
The CP/M filesystem also has some interesting performance features, such as the filesystem metadata being contained in the directory area.
Re: (Score:2)
Agreed. I see this as happy news. At least Overstreet has a chance to continue development, make improvements, drum up PR, get some enthusiastic users or distros that are willing to apply patches, and eventually prove the filesystem has enough merit to gain adoption. Unfortunately this change probably limits his ability to get funding, so I'm not optimistic. At least Overstreet is merely hard to work with, unlike the eponymous author of ReiserFS and Reiser4.
Re:Sad (Score:5, Interesting)
There is also zfs, which is also a great option.
Re: (Score:2)
At that point, we might as well use LVM2's caching, as an option.
Re: (Score:2)
This reply smells of someone that has never used both.
bcache by itself is rather inefficient. That's why bcachefs was born.
It works soooooooo much better.
Re: (Score:2)
bcachefs is not about the caching. It is about snapshots, checksums, etc. It only shares some code with bcache.
Re: Sad (Score:2)
Says the the anonymous coward.
Plenty of positive talk about MacOS use. It's more "Anything but Windows" at most.
Re: (Score:2)
I resemble that comment, with MacOS as my daily-driver and work all day on Linux, w/FreeBSD for personal servers.
Re: (Score:3)
It may not be in the kernel, but you can do all of that with ZFS. It has some pretty serious limitations though, like they insist that you not trust a SLOG which is not battery backed, and that you not use cheap hard drives (with shingled recording) while the I in RAID literally means inexpensive. They also insist that you will have problems if you have disks on USB. All of those things may be bad ideas, but people commonly want to do them, and finding ways to accommodate them is a reasonable ask.
To use a c
Re: (Score:2)
The question is would other filesystems (bcachefs or btrfs) be more resilient to the journal randomly disappearing, hard drives that are really bad at random writes (way worse than regular hard drives) or having drives randomly disappear and reappear.
Drive-managed SMR sucks in most cases, but it really sucks for zfs rebuilds. I think there are plans to make zfs more compatible with SMR, but they are probably not the highest priority. There were even plans to make zfs compatible with object storage, but they
Re: (Score:2)
Drive-managed SMR sucks in most cases
Is there any other kind? I though it had to be because only the drive has enough info and control to actually execute that process.
Re: (Score:2)
There's host-managed SMR, where the drive exposes the management to the OS, so the OS can decide where to write the data. The OS has to write the data to the drive sequentially. There's also a middle-ground, called Host-Aware SMR, where the drive can manage the writes, but the OS can see the zones.
The way SMR looks from the OS is not that different from a SSD. The drive has large zones (256MB or so) that are append-only. You can write data to the zone, append it, but if you want to overwrite previously writ
Re: (Score:2)
Well I don't have anything to add other than TIL
thanks for the really great explanation.
Re: (Score:2)
None of these issues are zfs specific though. All of them are bad ideas on any storage solution that you want to be reliable. Raid or not. Since zfs wants to be reliable, they are warning you about it.
Still, whatever zfs insists, you can do what you want. But if what you want is to use SMR drives for a raid, zfs or not, where data gets updated, you are doing it wrong. These drives are not meant for that. They are actually incompatible with that, and the information about that is not secret and should be com
Re: (Score:3)
Re: (Score:2)
> To be able to use a SSD as a cache for hard drive (RAID) array is a very useful use case
Why does this need to be implemented as part of a file system though?
I think a trend I really hate lately is that file systems are trying to manage everything, starting with ZFS and some of the same mentality bleeding into btrfs. LVM+MD already implement (and implement well) the features they're trying to make file systems do as well. And LVM+MD is both rock solid and doesn't make implementing VMs (for instance) les
Re: (Score:2)
"So let's make a file system that also has RAID in it! And hookers! And blackjack! And it can brush your teeth! And make thousands of jullienne fries!"
At this point, can we just ask Mr. Lennart Poettering to design our ultimate filesystem?
Re: (Score:2)
Looks like new filesystems have a tendency... (Score:3)
Re: (Score:2)
The ironic thing is that we need new filesystems. btrfs has had some changes, but it really needs the fscrypt mods mainlined, and if we can get Synology to push their "Lock & Roll" stuff to mainline, it will go a long way for immutability. Btrfs still has concerns on the write hole front, and it desperately needs an encryption layer built in for performance reasons, because FDE is a must these days... and no, LUKS doesn't cure everything.
What we REALLY need is a filesystem like VMFS. A checksumming,
Re: (Score:3)
... to require so many changes in different parts of the kernel that those are hard to justify and agree upon for only the benefit of that particular new filesystem. Reminds me of the long struggle to get "reiser4" into the kernel, which ultimately never happened, and that was not just because its name got an awkward connotation.
I guess the integration effort was murder.
Re: (Score:3)
There are many different file systems out there today to accommodate many different use cases. However, the really innovative stuff is much harder to implement without breaking existing functionality. I can't help but w
Re: (Score:2)
Yeah it turns out that filesystems are complicated. Like really really complicated.
Umm, From June? (Score:4, Informative)
"In June 2025, Linus Torvalds announced bcachefs would be ejected from the kernel as a result of repeated violations of kernel development guidelines.
Wikipedia on bcachrefs [wikipedia.org]
Re: Umm, From June? (Score:1)
I don't know where Wikipedia got their supposed information from, but the git commit making this change was time-stamped 2025-08-28 15:16:16
Re: (Score:3)
They literally cited it, as is normal at Wikipedia.
https://lore.kernel.org/all/CA... [kernel.org]
The git commit isn't the announcement, it's the implementation.
Linus Torbalds? (Score:2)
Interesting (Score:2)
And did the narcissistic inbred fart lately?
Name (Score:1)
I admit I wondered for quite a while what bca chefs are.
Cost/benefit calculation (Score:2)
You can only deal with problematic developers for so long. There comes a time when you realise that trying to make someone behave is a futile pursuit and having that member on the team provides more negatives than positives. Happens in every team, sooner or later. He's made the right call.
Who are the Bca chefs? (Score:2)
What kind of food do they cook? ;-) )
( Didn't RTFA.
Probably for the best - Very active development... (Score:2)
As an example, BTRFS has started to stagnate in development. Nothing really ground breaking has happened with BTRFS. In someways, it is a dead file system and headed for the scrap heap, (note I said SOMEWAYS). I personally used BTRFS, both because it was supposed to be the replacement for EXT3/4, had data integrity features, plus snapshots. Even went so far as to write up a l
Re: (Score:2)
bcachefs has one developer. It's "active" but extremely vulnerable.
btrfs hasn't stagnated from what I've seen, it's just reached a point of being pretty much feature complete and according to some reports bug free too (supposedly the issues with btrfs's built-in RAID5 and RAID6 implementation were fixed two or three years ago, but obviously it takes time for the fixes to come forward.)
What features do you think are important that btrfs doesn't have?