Re: [GIT PULL] bcachefs fixes for 6.12-rc2

Martin Steigerwald
2024-10-06T11:56:30Z

Hi Kent, hi Linus.

Kent Overstreet - 06.10.24, 02:54:32 CEST:
> On Sat, Oct 05, 2024 at 05:14:31PM GMT, Linus Torvalds wrote:
> > On Sat, 5 Oct 2024 at 16:41, Kent Overstreet
<kent.overstreet@linux.dev> wrote:
> > > If what you want is patches appearing on the list, I'm not unwilling
> > > to
> > > make that change.
> >
> > I want you to WORK WITH OTHERS. Including me - which means working
> > with the rules and processes we have in place.
>
> That has to work both ways.

Exactly, Kent.

And it is my impression from reading the whole thread up to now and from
reading previous threads it is actually about: Having your way and your
way only.

That is not exactly "work both ways".

Quite similarly regarding your stand towards distributions like Debian.

Sure you can question well established rules all the way you want and
maybe you are even right about it. I do not feel qualified enough to judge
on that. I am all for challenging well established rules on justified
grounds…

But… even if that is the case it is still a negotiation process. Expecting
that communities change well established rules on the spot just cause you
are asking for it… quite bold if you ask me. It would be a negotiation
process and work both ways would mean to agree on some kind of middle
ground. But it appears to me you do not seem to have the patience for such
a process. So it is arguing on both sides which costs a lot of energy of
everyone involved.

From what I perceive you are actually actively working against well
established rules. And you are surprised on the reaction? That is kind of
naive if you ask me.

At least you wrote you are willing to post patches to the mailing list: So
why not start with at least that *minimal* requirement according to Linus
as a step you do? Maybe even just as a sign of good will towards the
kernel community? That has been asked of you concretely, so why not just
do it?

Maybe this can work out by negotiating a middle ground going one little
step at a time?

I still do have a BCacheFS on my laptop for testing, but meanwhile I
wonder whether some of the crazy kernel regressions I have seen with the
last few kernels where exactly related to having mounted that BCacheFS
test filesystem. I am tempted to replace the BCacheFS with a BTRFS just to
find out.

Lastly 6.10.12-1 Debian kernel crashes on a pool-spawner thread when I
enter the command „reboot“. That is right a reboot crashes the system – I
never have seen anything this crazy with any Linux kernel so far! I have
made a photo of it but after that long series of regressions I am even too
tired to post a bug report about it just to be told again to bisect the
issue. And it is not the first work queue related issue I found between 6.8
and 6.11 kernels.

Actually I think I just replace that BCacheFS with another BTRFS in order
to see whether it reduces the amount of crazy regressions I got so fed up
with recently. Especially its not fair to report all of this to the Lenovo
Linux community guy Mark Pearson in case its not even related to the new
ThinkPad T14 AMD Gen 5 I am using. Mind you that series of regressions
started with a T14 AMD Gen 1 roughly at the time I started testing
BCacheFS and I had hoped they go away with the new laptop. Additionally I
have not seen a single failure with BTRFS on any on my systems – including
quite some laptops and several servers, even using LXC containers – for… I
don't remember when. Since kernel 4.6 BTRFS at least for me is rock
stable. And I agree, it took a huge lot of time until it was stable. But
whether that is due to the processes you criticize or other reasons or a
combination thereof… do you know for sure?

I am wondering: did the mainline kernel just get so much more unstable in
the last 3-6 months or may there be a relationship to the test BCacheFS
filesystem I was using that eluded me so far. Of course, I do not know for
now, but reading Carl's mails really made me wonder.

Maybe there is none, so don't get me wrong… but reading this thread got me
suspicious now. I am happily proven wrong on that suspicion and I commit
to report back on it. Especially when the amount of regressions does not
decline and I got suspicious of BCacheFS unjustly.

Best,
--
Martin