linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.16-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <hewwxyayvr33fcu5nzq4c2zqbyhcvg5ryev42cayh2gukvdiqj@vi36wbwxzhtr>
Date: Fri, 20 Jun 2025 04:14:24 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Martin Steigerwald <martin@...htvoll.de>
Cc: 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 09:12:21AM +0200, Martin Steigerwald wrote:
> Hi Kent, hi,
> 
> Kent Overstreet - 20.06.25, 03:51:45 CEST:
> > On Fri, Jun 20, 2025 at 04:25:58AM +0300, Jani Partanen wrote:
> > > On 20/06/2025 4.09, Kent Overstreet wrote:
> > > > I'm not seeing that _you_ get that.
> > > 
> > > How hard it is?
> > > 
> > > New feature window for 6.16 was 2 weeks ago.
> > > 
> > > rc<insert number here> is purely for fixing bugs, not adding new
> > > features and potential new bugs.
> > 
> > That's an easy rule for the rest of the kernel, where all your mistakes
> > are erased at a reboot. Filesystems don't have that luxury.
> > 
> > In the past, I've had to rush entire new on disk format features in
> > response to issues I saw starting to arise - I think more than once, but
> > the btree bitmap in the member info section was the big one that sticks
> > in my mind; that one was very hectic, but 100% proved its worth.
> 
> Kent, from what I gathered, you'd like to change some window rules – at 
> least for filesystems or new-in-kernel filesystems.

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.

There's no need for any of this micromanaging, which is what this has
turned into. All it's been doing is generating conflict and drama.

> > For a lot of users, compiling a kernel from some random git repository
> > is a lot to ask. I spend a lot of time doing what amounts to support;
> > that's just how it is these days. But rc kernels are packaged by most
> > kernels, and we absolutely do not want to wait an additional 3 months
> > for it to show up in a release kernel -
> 
> Those users should probably not use BCacheFS right now already to begin 
> with but wait for it to be marked as stable?

I've often told people that they should probably wait before switching,
particularly when they need features that aren't ready yet (erasure
coding), and things are not yet so trouble free that I would recommend
normal users switch.

Besides the most basic "will it eat your data", there's a lot of other
things to consider, like "is it providing stable backports yet" (I'm
explicitly not) or "is there wonky behaviour or missing APIs still to be
worked out" (yes, there definitely is, and I'm still triaging so there
will be awhile).

None of that changes my most basic responsibility.

> Kent Overstreet - 20.06.25, 03:09:07 CEST:
> > There are a _lot_ of people who've been burned by btrfs. I've even been
> > seeing more and more people in recent discussions talking about
> > unrecoverable filesystems with XFS (!).
> 
> And I have seen a lot of threads on XFS over the years where XFS 
> developers went great lengths to help users recover their data. I have 
> seen those threads also on the BTRFS mailing list. Those users had no 
> support contract, they did not pay anything for that free service either.
> 
> So I am not sure it is wise or even just accurate to implicitly imply that 
> other than BCacheFS filesystem developers do not care about user data. 
> From what I have seen I conclude: They do!

No, I'm not saying that they don't care about user data.

I know most of the other filesystem developers, particularly the XFS
ones; I'm not trying to disparage their work.

But track records do matter, and bcachefs has a good one, and I intend
to keep it that way.