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

[Martin Steigerwald]

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@xxxxxxxxx> 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