Message-ID: <bwhemajjrh7hao5nzs5t2jwcgit6bwyw42ycjbdi5nobjgyj7n@4nscl4fp6cjo>
Date: Fri, 20 Jun 2025 19:34:54 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Theodore Ts'o <tytso@....edu>
Cc: Martin Steigerwald <martin@...htvoll.de>, 
	Jani Partanen <jiipee@...apeli.fi>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.16-rc3

On Fri, Jun 20, 2025 at 08:43:46AM -0400, Theodore Ts'o wrote:
> On Fri, Jun 20, 2025 at 04:14:24AM -0400, Kent Overstreet wrote:
> > 
> > There is a time and a place for rules, and there is a time and a place
> > for using your head and exercising some common sense and judgement.
> > 
> > I'm the one who's responsible for making sure that bcachefs users have a
> > working filesystem. That means reading and responding to every bug
> > report and keeping track of what's working and what's not in
> > fs/bcachefs/. Not you, and not Linus.
> 
> Kent, the risk as always of adding features after the merge window is
> that you might introduce regressions.  This is especially true if you
> are making changes to relatively sensitive portions of any file system
> --- such as journalling.

Ted, you know better than most how long I've been shipping storage code.

You also know just as well as I do that when to include a patch is very
much a judgement call, so I'm quite curious why you and Linus think
yourselves better able to make that judgement call than I.

> The rules around the merge window is something which the vast majority
> of the kernel developers have agreeded upon for well over a decade.
> And it is Linus's responsibility to *enforce* those rules.

And those rules are _always_ flexible when there's a reason for them to
be, and here we do have a very good reason for including that code -
making sure people don't lose filesystems.

> If, as you say, bcachefs is experimental, and no sane person should be
> trusting their data on it, then perhaps this shouldn't be urgent. 

I don't see how that follows.

Firstly, we're not defining what the "experimental" label, and since I
am the one who put that label on bcachefs, I'll define that now.

Primarily:

- Bugs are still outstanding, so users should not expect the same level
  of polish as other filesystems - but that does _not_ mean that it's
  not supported to the same degree as other filesystems. Bug reports are
  triaged, and anything that effects the filesystem as a whole will be
  fixed with great immediacy: "polish" issues or bugs that only affect a
  specific application, or a new feature, might have to wait.

- Stable backports are only happening for the most critical bugs, due to
  the volume of bugfixing. Users are expected to stick close to the
  latest release if they want a fix, and often run rc kernels if there's
  something specific they need. This has been working well, because the
  rate of _regressions_ has been quite low.

And that's basically it.

This isn't btrfs, which took off the experimental label, as I recall,
when the on disk format was frozen. bcachefs's on disk format hasn't
been making incompatible changes in years, and as of 6.15 the last of
the required on disk format upgrades is done.

I'll be taking off the experimental label when I believe bcachefs ready
for widespread deployment by the distributions, not before.

Again, that _does not mean_ that I'm not supporting it like any other
production filesystem is supported. I think user reports should have
made that clear by now.

The talk about "no sane person should trust their data to it" is
entirely baseless - I honestly don't know where you and Linus are
getting that from. It's certainly not based on user reports or anything
I've seen.

bcachefs has been used in production for years, by a small but growing
number of users, and at this point 100+tb filesystems in production are
commonplace. I have one user I work with closely who can rattle off a
long list of workloads he's got on bcachefs, and the only reason he
isn't moving more stuff off of btrfs is send/recv - it'll be a long time
before we have that.

> On the flip side, perhaps if you are claiming that people should be
> using it for critical data, then perhaps your care for user's data
> safety should be.... revisted.

This seems entirely backwards. Whatever I'm claiming is besides the
point: bcachefs has users, and I actively support them.

Now, onwards:

It's _entirely_ unclear why you and Linus are bringing up the
experimental label of bcachefs.

If bcachefs were seen as a widely deployed, non-experimental filesystem
(despite the fact that for all purposes it is), I have to think - I have
to hope - that you'd be taking a more pragmatic approach here.

But I think I and myself would assume that having an experimental label
would mean _looser_ rules, so that development can move more quickly.

So it's hard to fathom what's going on here.

Powered by blists - more mailing lists