[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nxyp62x2ruommzyebdwincu26kmi7opqq53hbdv53hgqa7zsvp@dcveluxhuxsd>
Date: Fri, 23 Aug 2024 22:33:18 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.11-rc5
On Sat, Aug 24, 2024 at 10:25:02AM GMT, Linus Torvalds wrote:
> On Sat, 24 Aug 2024 at 10:14, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> > On Sat, Aug 24, 2024 at 09:23:00AM GMT, Linus Torvalds wrote:
> > > On Sat, 24 Aug 2024 at 02:54, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> > > >
> > > > Hi Linus, big one this time...
> > >
> > > Yeah, no, enough is enough. The last pull was already big.
> > >
> > > This is too big, it touches non-bcachefs stuff, and it's not even
> > > remotely some kind of regression.
> > >
> > > At some point "fix something" just turns into development, and this is
> > > that point.
> > >
> > > Nobody sane uses bcachefs and expects it to be stable, so every single
> > > user is an experimental site.
> >
> > Eh?
> >
> > Universal consensus has been that bcachefs is _definitely_ more
> > trustworthy than brtfs,
>
> I'll believe that when there are major distros that use it and you
> have lots of varied use.
Oh, I'm waiting for that hammer to drop too.
But: all the data we've got so far is that it really is shaping up to be
that solid, there's clearly been big upticks in users as it went
upstream, as distros have been rolling it out, and the uptick in bug
reports hasn't been there.
> But it doesn't even change the issue: you aren't fixing a regression,
> you are doing new development to fix some old probl;em, and now you
> are literally editing non-bcachefs files too.
What is to be gained by holding back fixes, if we've got every reason to
believe that the fixes are solid?
And yes, these _are_ solid, the rhashtable stuff was done months ago
(minus the deadlock fix, that's more recent), and the rcu_pending stuff
was mostly done months ago as well, and _heavily_ tested (including
using it as replacement backend for kvfree_rcu, which is the eventual
goal there).
And the genradix code is code that I also wrote and maintain, and those
are simple patches.
Powered by blists - more mailing lists