All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Kent Overstreet <kent.overstreet@linux.dev>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Gerhard Wiesinger <lists@wiesinger.com>
Cc: linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [GIT PULL] bcachefs changes for 6.17
Date: Sun, 10 Aug 2025 12:32:38 +0200	[thread overview]
Message-ID: <22799288.EfDdHjke4D@lichtvoll.de> (raw)
In-Reply-To: <e19849f2-4a39-4a09-b19e-cb4f291a2dc2@wiesinger.com>

Hi Gerhard, hi.

Gerhard Wiesinger - 10.08.25, 08:20:43 CEST:
> On 28.07.2025 17:14, Kent Overstreet wrote:
> > Schedule notes for users:
> > 
> > I've been digging through the bug tracker and polling users to see
> > what bugs are still outstanding, and - it's not much.
> > 
> > So, the experimental label is coming off in 6.18.
> > 
> > As always, if you do hit a bug, please report it.
> 
> I can now confirm that bcachefs is getting stable and the test cases
> with intentionally data corruption (simulation of a real world case I
> had) gets bcachefs back to a consistent state (after 2 runs of: bcachefs
> fsck -f -y ${DEV}). That's a base requirement for a stable filesystem.
> Version of bcachefs-tools is git
> 530e8ade4e6af7d152f4f79bf9f2b9dec6441f2b and kernel is
> 6.16.0-200.fc42.x86_64.
> 
> See for details, I made data corruption even worser with running the
> destroy script 5x:
> 
> https://lore.kernel.org/linux-bcachefs/aa613c37-153c-43e4-b68e-9d50744be
> 7de@wiesinger.com/
> 
> Great work Kent and the other contributors.
> 
> Unfortunately btrfs can't be repaired to a consistent state with the
> same testcase. I'd like to be that testcase fixed also for BTRFS as a
> stable filesystem (versions: 6.16.0-200.fc42.x86_64, btrfs-progs v6.15,
> -EXPERIMENTAL -INJECT -STATIC +LZO +ZSTD +UDEV +FSVERITY +ZONED
> CRYPTO=libgcrypt).
> 
> (I reported that already far in the past on the mailing list, see here:
> https://lore.kernel.org/linux-btrfs/63f8866f-ceda-4228-b595-e37b016e7b1f
> @wiesinger.com/).

Thanks for this great find and these test results.

On a technical perspective I still think the Linux kernel is a better 
kernel with BCacheFS included.

And write this without having had any issues – except for bad performance 
especially on hard disks, but partly also on flash – with BTRFS. And I use 
it on a couple laptops, some virtual machines and a lot of external disks. 
But not on a multi device setup. I had a BTRFS RAID 1 for a long time. 
This also has been stable since kernel 4.6 up to the time I still used it.

So I did not really have much of a need to fsck BTRFS.

Best,
-- 
Martin



      reply	other threads:[~2025-08-10 10:32 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-28 15:14 [GIT PULL] bcachefs changes for 6.17 Kent Overstreet
2025-08-05 21:19 ` Malte Schröder
2025-08-05 22:41   ` Carl E. Thompson
2025-08-07 12:42     ` Aquinas Admin
2025-08-09 17:36       ` Kent Overstreet
2025-08-09 19:21         ` Josef Bacik
2025-08-09 20:37           ` Kent Overstreet
2025-08-09 21:34             ` Kent Overstreet
2025-08-10  2:24             ` Theodore Ts'o
2025-08-10  3:17               ` Kent Overstreet
2025-08-10  4:05                 ` Sasha Levin
2025-08-10  4:13                   ` Kent Overstreet
2025-08-10  4:26                     ` Gerald B. Cox
2025-08-10  5:17                       ` Kent Overstreet
2025-08-10  5:59                       ` Theodore Ts'o
2025-08-10  6:51                         ` Kent Overstreet
2025-08-10 10:22                         ` Martin Steigerwald
2025-08-11 15:48                         ` Peanut gallery 2c James Lawrence
2025-08-11 16:08                           ` Kent Overstreet
2025-08-11 17:00                             ` James Lawrence
     [not found]                             ` <aJsIOj6jbPKayO0s@mayhem.fritz.box>
2025-08-12 16:26                               ` Kent Overstreet
2025-08-11 16:48                   ` [GIT PULL] bcachefs changes for 6.17 Aquinas Admin
2025-08-10  8:02                 ` Martin Steigerwald
2025-08-10  6:05               ` Carl E. Thompson
2025-08-11 16:02           ` Aquinas Admin
2025-08-11 16:09             ` Kent Overstreet
2025-08-09 23:01         ` Matthew Wilcox
2025-08-09 23:13           ` Kent Overstreet
2025-08-12  7:49             ` Jani Partanen
2025-08-12 10:09               ` Martin Steigerwald
2025-08-11  9:51         ` Konstantin Shelekhin
2025-08-11 14:26           ` Kent Overstreet
2025-08-11 18:13             ` Carl E. Thompson
2025-08-11 18:40               ` Malte Schröder
2025-08-12  0:44                 ` Carl E. Thompson
2025-08-11 18:48               ` Aquinas Admin
2025-08-11 19:42               ` Martin Steigerwald
2025-08-11 21:04             ` Konstantin Shelekhin
2025-08-12  1:08               ` Kent Overstreet
2025-08-12  6:52             ` asdx
2025-08-12  7:04               ` Kent Overstreet
2025-08-12  7:17                 ` asdx
2025-08-12 19:35             ` Keith Busch
2025-08-12 20:03               ` Kent Overstreet
2025-08-12 20:30                 ` Keith Busch
2025-08-12 20:31                   ` Kent Overstreet
2025-08-12 20:38                     ` Keith Busch
2025-08-12 20:45                       ` Kent Overstreet
2025-08-12 20:54                         ` Keith Busch
2025-08-12 20:57                           ` Kent Overstreet
2025-08-11 16:45           ` Aquinas Admin
2025-08-10  4:29       ` Gerhard Wiesinger
2025-08-07 14:27   ` Martin Steigerwald
2025-08-07 17:29   ` Peter Schneider
2025-08-10  6:20 ` Gerhard Wiesinger
2025-08-10 10:32   ` Martin Steigerwald [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22799288.EfDdHjke4D@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lists@wiesinger.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.