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

[Josef Bacik]

On Sat, Oct 05, 2024 at 06:54:19PM -0400, Kent Overstreet wrote:
> On Sat, Oct 05, 2024 at 03:34:56PM GMT, Linus Torvalds wrote:
> > On Sat, 5 Oct 2024 at 11:35, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
> > >
> > > 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.
> 
> > 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.
> 
> > 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.
> 
> And many, many people talking about how even at this relatively early
> point it doesn't fall over like btrfs does.
> 

I tend to ignore these kind of emails, it's been a decade and weirdly the file
system development community likes to use btrfs as a punching bag.  I honestly
don't care what anybody else thinks, but I've gotten feedback from others in the
community that they wish I'd say something when somebody says things so patently
false.  So I'm going to respond exactly once to this, and it'll be me satisfying
my quota for this kind of thing for the rest of the year.

Btrfs is used by default in the desktop spin of Fedora, openSuse, and maybe some
others.  Our development community is actively plugged into those places, we
drop everything to help when issues arise there.  Btrfs is the foundation of the
Meta fleet.  We rely on its capabilities and, most importantly of all, its
stability for our infrastructure.

Is it perfect?  Absolutely not.  You will never hear me say that.  I have often,
and publicly, said that Meta also uses XFS in our database workloads, because it
simply is just better than Btrfs at that.

Yes, XFS is better at Btrfs at some things.  I'm not afraid to admit that,
because my personal worth is not tied to the software projects I'm involved in.
Dave Chinner, Darrick Wong, Christoph Hellwig, Eric Sandeen, and many others have
done a fantastic job with XFS.  I have a lot of respect for them and the work
they've done.  I've learned a lot from them.

Ext4 is better at Btrfs in a lot of those same things.  Ted T'so, Andreas
Dilger, Jan Kara, and many others have done a fantastic job with ext4.

I have learned a lot from all of these developers, all of these file systems,
and many others in this community.

Bcachefs is doing new and interesting things.  There are many things that I see
you do that I wish we had the foresight to know were going to be a problem with
Btrfs and done it differently.  You, along with the wider file system community,
have a lot of the same ideals, same practices, and same desire to do your
absolute best work.  That is an admirable trait, one that we all share.

But dragging other people and their projects down is not the sort of behavior
that I think should have a place in this community.  This is not the kind of
community I want to exist in.  You are not the only person who does this, but
you are the most vocal and constant example of it.  Just like I tell my kids,
just because somebody else is doing something wrong doesn't mean you get to do
it too.

We can improve our own projects, we can collaborate, and we can support
each others work.  Christian and I tag-teamed the mount namespace work.  Amir
and I tag-teamed the Fanotify HSM work.  Those two projects are the most fun and
rewarding experiences I've had in the last few years.  This work is way more fun
when we can work together, and the relationships I've built in this community
through this collaboration around solving problems are my most cherished
professional relationships.

Or we can keep doing this, randomly throwing mud at each other, pissing each
other off, making ourselves into unhireable pariahs.  I've made my decision, and
honestly I think it's better.

But what the fuck do I know, I work on btrfs.  Thanks,

Josef