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