Re: [GIT PULL] bcachefs fixes for 6.16-rc4

[Kyle Sanderson <kyle.leet@gmail.com>]

On 6/26/2025 8:21 PM, Linus Torvalds wrote:
> On Thu, 26 Jun 2025 at 19:23, Kent Overstreet <kent.overstreet@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.