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: <lyvczhllyn5ove3ibecnacu323yv4sm5snpiwrddw7tyjxo55z@6xea7oo5yqkn>
Date: Thu, 19 Jun 2025 21:09:07 -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.16-rc3

On Thu, Jun 19, 2025 at 05:51:17PM -0700, Linus Torvalds wrote:
> On Thu, 19 Jun 2025 at 16:06, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
> >
> > - New option: journal_rewind
> >
> >   This lets the entire filesystem be reset to an earlier point in time.
> >
> >   Note that this is only a disaster recovery tool, and right now there
> >   are major caveats to using it (discards should be disabled, in
> >   particular), but it successfully restored the filesystem of one of the
> >   users who was bit by the subvolume deletion bug and didn't have
> >   backups. I'll likely be making some changes to the discard path in the
> >   future to make this a reliable recovery tool.
> 
> You seem to have forgotten what the point of the merge window was again.

The goal is to get users _code that works_, is it not?

> We don't start adding new features just because you found other bugs.
> 
> I remain steadfastly convinced that anybody who uses bcachefs is
> expecting it to be experimental. They had better.

Honestly, most of the people using bcachefs from what I've seen just
want something that works.

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 (!).

That last one has been a surprise to me (and I don't think it's anything
to do with the quality of the code), but it honestly should serve as a
wakeup call as to how much is falling through the cracks and how badly
we've been failing.

There are still a lot of people who don't want to move off ext4... and I
can't really blame them.

If you go looking, you won't find those stories about bcachefs - except
from me, when I'm telling people what to watch out for.

And that's because of a lot of hard work, and because I'm dead set on
not repeating past mistakes; I actively hunt down bug reports and I
frequently tell people - "I don't care if you think it's a hardware
issue or pebcak, it's the filesystem's job to not lose data; get me the
info I need and I'll get it sorted and get it working again".

That's the goal here, delivering something that users can trust and rely
on.

I'm not seeing that _you_ get that.