Linus Torvalds Begins Expressing Regrets Merging Bcachefs
([Linux Storage] 5 Hours Ago
Bcachefs Regrets)
- Reference: 0001487364
- News link: https://www.phoronix.com/news/Linus-Torvalds-Bcachefs-Regrets
- Source link:
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 [1]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.
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 [2]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.
[1] https://lore.kernel.org/lkml/sctzes5z3s2zoadzldrpw3yfycauc4kpcsbpidjkrew5hkz7yf@eejp6nunfpin/
[2] https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/
On Friday a set of fixes were [1]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.
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 [2]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.
[1] https://lore.kernel.org/lkml/sctzes5z3s2zoadzldrpw3yfycauc4kpcsbpidjkrew5hkz7yf@eejp6nunfpin/
[2] https://lore.kernel.org/lkml/CAHk-=wj1Oo9-g-yuwWuHQZU8v=VAsBceWCRLhWxy7_-QnSa1Ng@mail.gmail.com/
Quackdoc