My vid is brought about because of this [GIT PULL] bcachefs fixes for 6.12-rc2
Thanks for all the comments BTW!
Here are my 3 points listed:
Q1: You keep saying "this" in the video and I'm not sure I really follow, do you have just the one example?
Lets look at one answer Kent has for Linus. I will be putting my comments in BOLD (source [GIT PULL] bcachefs fixes for 6.12-rc2
On Sat, Oct 05, 2024 at 03:34:56PM GMT, Linus Torvalds wrote:
> On Sat, 5 Oct 2024 at 11:35, Kent Overstreet
> >
> > Several more filesystems repaired, thank you to the users who have been
> > providing testing. The snapshots + unlinked fixes on top of this are
> > posted here:
>
> I'm getting really fed up here Kent.
>
> These have commit times from last night. Which makes me wonder how
> much testing they got.
The /commit/ dates are from last night, because I polish up commit
messages and reorder until the last might (I always push smaller fixes
up front and fixes that are likely to need rework to the back).
The vast majority of those fixes are all ~2 weeks old. Doesn't address Linus's concern of testing
> And before you start whining - again - about how you are fixing bugs,
> let me remind you about the build failures you had on big-endian
> machines because your patches had gotten ZERO testing outside your
> tree.
No, there simply aren't that many people running big endian. I have
users building and running my trees on a daily basis. If I push
something broken before I go to bed I have bug reports waiting for me
_the next morning_ when I wake up. not that many people running something isn't an excuse but ok...
> That was just last week, and I'm getting the strong feeling that
> absolutely nothing was learnt from the experience.
>
> I have pulled this, but I searched for a couple of the commit messages
> on the lists, and found nothing (ok, I found your pull request,
> which obviously mentioned the first line of the commit messages).
>
> I'm seriously thinking about just stopping pulling from you, because I
> simply don't see you improving on your model. If you want to have an
> experimental tree, you can damn well have one outside the mainline
> kernel. I've told you before, and nothing seems to really make you
> understand.
At this point, it's honestly debatable whether the experimental label
should apply. I'm getting bug reports that talk about production use and
working on metadata dumps where the superblock indicates the filesystem
has been in continuous use for years. How is this an argument for being stable? anecdotal much?
And many, many people talking about how even at this relatively early
point it doesn't fall over like btrfs does.
Let that sink in.
Btrfs has been mainline for years, and it still craps out on people. I
was just in a meeting two days ago, closing funding, and a big reason it
was an easy sell was because they have to run btrfs in _read only_ mode
because otherwise it craps out. if my #2 isn't yelling in your mind, i don't know what will
So if the existing process, the existing way of doing things, hasn't
been able to get btrfs to a point where people can rely on it after 10
years - perhaps you and the community don't know quite as much as you
think you do about the realities of what it takes to ship a working
filesystem. BTW Linus told Kent repeatedly that the reason why the rules are they way they are is to make sure we don't make the same mistakes than with BTRFS. the standards have changed in the last 10 years
And from where I sit, on the bcachefs side of things, things are going
smoothly and quickly. Bug reports are diminishing in frequency and
severity, even as userbase is going up; distros are picking it up (just
not Debian and Fedora); the timeline I laid out at LSF is still looking
reasonable.
> I was hoping and expecting that bcachefs being mainlined would
> actually help development. It has not. You're still basically the
> only developer, there's no real sign that that will change, and you
> seem to feel like sending me untested stuff that nobody else has ever
> seen the day before the next rc release is just fine.
I've got a team lined up, just secured funding to start paying them and
it looks like I'm about to secure more.
And the community is growing, I'm reviewing and taking patches from more
people, and regularly mentoring them on the codebase.
And on top of all that, you shouting about "process" rings pretty hollow
when I _remember_ the days when you guys were rewriting core mm code in
rc kernels. emmm he is making the argument to leave BcacheFS out of the kernel right?
Given where bcachefs is at in the lifecycle of a big codebase being
stabilized, you should be expecting to see stuff like that here. Stuff
is getting found and fixed, and then we ship those fixes so we can find
the next stuff.
> You're a smart person. I feel like I've given you enough hints. Why
> don't you sit back and think about it, and let's make it clear: you
> have exactly two choices here:
>
> (a) play better with others
>
> (b) take your toy and go home
You've certainly yelled a lot...
now if that message isn't clear, he dodge all the concerns of Linus and pointed to BTRFS...
On Sat, Oct 05, 2024 at 07:41:03PM GMT, Kent Overstreet wrote:
> Face _what_ exactly? Because at this point, I can't even tell what it is
> you want, what you're reacting to keeps shifting.
And more than that, I'm done with trying to cater, and I'm done with
these long winded rants. Look, I quite enjoy the direct approach, but
I'm done with having to apologize for you in order to calm people down
every time this happens.
If you're so convinced you know best, I invite you to start writing your
own filesystem. Go for it.
This is beyond childish....
Yep, look at any conversation where Linus asks for the rules to be followed and you will see the same result.... here is another example Re: [GIT PULL] bcachefs fixes for 6.11-rc5 - Linus Torvalds