On 6/27/2025 12:07 PM, Kyle Sanderson wrote:
On 6/26/2025 8:21 PM, Linus Torvalds wrote:
On Thu, 26 Jun 2025 at 19:23, Kent Overstreet
<kent.overstr...@linux.dev> wrote:
per the maintainer thread discussion and precedent in xfs and btrfs
for repair code in RCs, journal_rewind is again included
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".
Linus
Linus,
The pushback on rewind makes sense, it wasn’t fully integrated and was
fsck code written to fix the problems with the retail 6.15 release -
this looks like it slipped through Kents CI and there were indeed
multiple people hit by it (myself included).
Quoting someone back to themselves is not cool, however I believe it
highlights what has gone on here which is why I am breaking my own rule:
"One of the things I liked about the Rust side of the kernel was that
there was one maintainer who was clearly much younger than most of the
maintainers and that was the Rust maintainer.
We can clearly see that certain areas in the kernel bring in more young
people.
At the Maintainer Summit, we had this clear division between the
filesystem people, who were very careful and very staid, and cared
deeply about their code being 100% correct - because if you have a bug
in a filesystem, the data on your disk may be gone - so these people
take themselves and their code very seriously.
And then you have the driver people who are a bit more 'okay',
especially the GPU folks, 'where anything goes'.
You notice that on the driver side it’s much easier to find young
people, and that is traditionally how we’ve grown a lot of maintainers.
" (1)
Kent is moving like the older days of rapid development - fast and
driven - and this style clashes with the mature stable filesystem
culture that demands extreme caution today. Almost every single patch
has been in response to reported issues, the primary issue here is
that’s on IRC where his younger users are (not so young, anymore - it is
not tiktok), and not on lkml. The pace of development has kept up, and
the "new feature" part of it like changing out the entire hash table in
rc6 seems to have stopped. This is still experimental, and he's moving
that way now with care and continuing to improve his testing coverage
with each bug.
Kent has deep technical experience here, much earlier in the
interview(1) regarding the 6.7 merge window this filesystem has been in
the works for a decade. Maintainership means adapting to kernel process
as much as code quality, that may be closer to the issue here.
If direct pulls aren’t working, maybe a co-maintainer or routing changes
through a senior fs maintainer can help. If you're open to it, maybe
that is even you.
Dropping bcachefs now would be a monumental step backward from the
filesystems we have today. Enterprises simply do not use them for true
storage at scale which is why vendors have largely taken over this
space. The question is how to balance rigor with supporting new
maintainers in the ecosystem. Everything Kent has written around
supporting users is true, and publicly visible, if only to the 260 users
on irc, and however many more are on matrix. There are plenty more that
are offline, and while this is experimental there are a number of public
sector agencies testing this now (I have seen reference to a number of
emergency service providers, which isn’t great, but for whatever reason
they are doing that).
(1) https://youtu.be/OvuEYtkOH88?t=1044
Kyle.
Re-sending as this thread seems to have typo'd lkml (removing the bad
entry).
Kyle.
