Linus Torvalds Begins Expressing Regrets Merging Bcachefs

There's been some Friday night kernel drama on the Linux kernel mailing list... Linus Torvalds has expressed regrets for merging the Bcachefs file-system and an ensuing back-and-forth between the file-system maintainer.

On Friday a set of fixes were submitted for merging into the current Linux 6.11 cycle. There were little fixes plus two big "fixes" around an rhashtable conversion and a new data structure for managing free lists in the BTree key cache. That later one eliminates the BTree key cache lock and avoids some locking contention that can appear in some multi-threaded workloads.
Bcachefs tag line
But this "fixes" pull request touches more than one thousand lines of code and we're now more than half-way through the Linux 6.11 cycle. This is far from the first time that big "fixes" pulls for Bcachefs have been submitted post merge window and not the first time that it's not strictly bug fixes but also heavier more feature-like additions being made via fixes pull requests. Linus Torvalds had enough and responded to the pull request:
"Yeah, no, enough is enough. The last pull was already big.

This is too big, it touches non-bcachefs stuff, and it's not even remotely some kind of regression.

At some point "fix something" just turns into development, and this is that point.

Nobody sane uses bcachefs and expects it to be stable, so every single user is an experimental site.

The bcachefs patches have become these kinds of "lots of development during the release cycles rather than before it", to the point where I'm starting to regret merging bcachefs.

If bcachefs can't work sanely within the normal upstream kernel release schedule, maybe it shouldn't *be* in the normal upstream kernel.

This is getting beyond ridiculous."
To which Kent responded and argued that "Bcachefs is _definitely_ more trustworthy than Btrfs", "I'm working to to make itmore robust and reliable than xfs and ext4 (and yes, it will be) with_end to end data integrity_," and other passionate commentary.

Torvalds then countered that there still aren't any major Linux distributions using Bcachefs, Linux kernel release rules should be followed, and the chances of new bugs coming up from 1000+ line patches of "fixes". There were several back-and-forth Friday night comments on the Linux kernel mailing list.

The Bcachefs "fixes" pull wasn't pulled and no revised pull request strictly limiting the changes to pure bug fixes have been submitted yet.
 
Soon we will have more fs`s than distro`s out there.
I'm kinda used to use ext4 on Linux but then i jumped to FreeBSD with zfs on WS and its a nice fs to use and im kinda getting towards - learn 1fs and be cool with it.
Now my VPS introduces Arch Linux and its on btrfs so i`m re-doing my WS to have Arch btrfs as my main drive but rest of the drives will be zfs to match FreeBSD and be happy with it i just have to learn few simple commands of btrfs and keep studying zfs and at some point just run root on zfs with Linux and wait for CUDA to be available in FreeBSD so i could finally ditch Linux and hope my VPS introduce FreeBSD but they don`t have a will to do so as of now.
 
i just have to learn few simple commands of btrfs
Evil Me wants to point you to tar()...

But I'm totally with Linus on this, having been a PL and merge monkey for some time - rejecting patches which touch many kloc when you can already see, smell, and touch the deadline is the only sane thing to do. Linus has the benefit not to have a PHB come to breath down your neck about it.
 
But I'm totally with Linus on this, having been a PL and merge monkey for some time - rejecting patches which touch many kloc when you can already see, smell, and touch the deadline is the only sane thing to do. Linus has the benefit not to have a PHB come to breath down your neck about it.
"Fixes" that touch over 1K lines of actual substance (not just whitespace changes) is usually because "we royally screwed up the design" or "I'm going to slip this new feature in".
I think Linus is correct to not pull it at this point in the cycle, heck the message reads rather tame to me. Almost "look if you had sent this during the first weeks of the cycle, maybe. Hold it until we start the next cycle and we can look at it then"
 
And when you find yourself in a hole, STOP digging.
To which Kent responded and argued that "Bcachefs is _definitely_ more trustworthy than Btrfs", "I'm working to to make itmore robust and reliable than xfs and ext4 (and yes, it will be) with_end to end data integrity_," and other passionate commentary.
Strawmanning is not helping. Your intentions don't matter, your goals don't matter, what you do in the commit does matter.

Had he said "Roger that, this is the minimal set which fixes critical bugs." he might have little effort to have a good spot in the next cycle. Trying to change core data structures in a "fix" is a big no-no which I'm sure Linus will remember the next cycle. A small set of minimal fixes without the extra updates and a note of "We know of these things (a b c ...) and have a patch, but it will be issued next cycle. Adventorous individuals may pull it on their own" would have gotten a nod from me for professional conduct and some goodwill in the future.
 
Well, I trust it way more than BTRFS.

Actual use here is ZFS when on Linux, of course ;)
Why do people dont trust BTRFS ? i tried few times but could not bother to utilize it but now after using zfs and need linux on the side - BTRFS sounds like a real nice option with raid.
 
This just seems like a disagreement on what to merge. 🤷‍♀️ Giant patch during dev cycle probably would be accepted.
 
Never had partition loss with any fs but i did lost 2 ssd at the same time. just stopped to work. it might be ext4 or zfs lol. but im blaming ssds not fs for piece of mind
 
Re BTRFS, even if it works perfect now and has for a year, there still is the afterglow from the dumpster fire it was, still the smell of the burned data, the echo of it's developers yelling of "you are using it wrong".
cracauer@ is right here - you need a big heap of professional developers and good processes to get such a complex pice of software trough the door. SUN had that, and I am sure early versions of ZFS did eat your data. But that was in a test lab, with good error reporting, post-mortems and serious debugging. But soon ZFS was stable enough to have developers use it themselves. And the rest is history.
 
This is a windows move.
Yeah,
standard procedure of the 'Windows 95 CD Installation CD' booting process:
First all drives found not having Windows installed wipe the MBR clean.
Then give the user a chance to interact.

So no need to achieve the same
by pretending engineering by doing a complex job within a 'casual environment of creative ideas flow free',
instead of doing real engineering:
Deal, and live with no release until independent hardball tests are passed.

But does this mean more people from Linux come here,
and ask how, and why not FreeBSD becomes more like Linux?
 
But does this mean more people from Linux come here,
and ask how, and why not FreeBSD becomes more like Linux?


:)

As pointed out by Crivens in #15, history is a lot to overcome, especially around filesystems.
What is the primary job of a filesystem? Store your data and not lose it.
Once a FS loses data even for a stupid bug, it's hard for users to regain trust, regardless of how many others have used it without issues.
 
Native ZFS seems to be a huge draw toward FreeBSD for a while now.
It is.
According to what I observe here in the forums for a many ZFS is the main, if not the only reason to decide for FreeBSD.
I'm also running ZFS, only - except on USB sticks.
And a good one I think.
Of course.
To me it's also a good idea if people join FreeBSD (who objects?)
But I simply had that feeling when systemd occurred also many changed to, or at least tested FreeBSD.
Again, not a bad thing.

The annoying thing I was referring to was the feeling I had too many were whining it's not exactly like Linux, and too many proposes changes to FreeBSD (more to Linux style).
That was I objecting to.
Of course not people join FreeBSD.
 
But does this mean more people from Linux come here,
and ask how, and why not FreeBSD becomes more like Linux?
That is only human. People flee one thing and then miss it, because it is familiar. This goes for people fleeing the middle east and then requesting sharia law, fleeing a country and then vote for policies turning the new place into the same, and yes, flee Linux and then ask why FreeBSD is not more like Linux and try to make it like it. Some people are not happy untill they are absolutely miserable.
 
Back
Top