From: Qu Wenruo <wqu@suse.com>
To: Zhang Boyang <zhangboyang.id@gmail.com>,
Qu Wenruo <quwenruo.btrfs@gmx.com>,
linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>, Filipe Manana <fdmanana@kernel.org>
Subject: Re: [BUG] two raid consistency bugs
Date: Wed, 15 Jul 2026 15:40:30 +0930 [thread overview]
Message-ID: <5eaba968-b8b9-4705-9027-9169942e105f@suse.com> (raw)
In-Reply-To: <4289be1b-285c-4641-a7b6-6b8e66f458c6@gmail.com>
在 2026/7/15 15:16, Zhang Boyang 写道:
> Hi,
>
> On 2026/7/15 05:40, Qu Wenruo wrote:
>>> At first power failure during transaction N, metadata trees of
>>> generation N are written to disk A, but super is not committed. Nothing
>>> is written to disk B.
>>>
>>> At second power failure during a different transaction N,
>>
>> If it's a different transaction, why it will still have the same
>> transid N?
>>
>
> Because the power failure occurred just before writing superblock
> (transid N). The superblock on disk still has transid N-1.
>
> After reboot, looking at superblock which transid is N-1, btrfs has no
> idea of transid N existed previously, so it uses transid N for new
> transcation.
Then there should be no problem at least at the next mount after the
power loss.
>
>>> nothing is
>>> written to disk A, but metadata trees and super is committed to disk B.
>>>
>>> This creates a ambiguous generation N in two disks. Currently btrfs
>>> can't detect this, and can lead to severe damages.
At the next mount, btrfs should detect device B has the latest super
block, and use that as the super block to mount.
Since metadata are all written to device B, even disk A may have some
stale tree blocks with transid N, stale tree blocks still need to meet
other conditions like root owner, level, first key checks.
I won't say that's impossible, and won't say we shouldn't do anything to
address it, but this is a variant of the split brain problems mentioned
in the past.
I strongly recommend to find out that thread and check if any of the
ideas are explored before and if they have their limits.
>
> By the way, I came up another solution:
>
> If generation mismatch between devices (or log-tree mismatch) is
> detected at mount time, set a dirty flag in superblock on device which
> is behind.
>
> If dirty flag is set for a device, disable read load balancing for that
> device. So (meta)data only read from latest device(s).
What if some metadata only arrives at that stale device, but not
completely reached the good device?
That kills the only chance to get the good metadata mirror.
And this won't solve the split brain situation either.
>
> If dirty flag is detected, ask user to run a scrub. The dirty flag is
> cleared after a successful scrub.
>
>
> Zhang Boyang
next prev parent reply other threads:[~2026-07-15 6:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 16:10 [BUG] two raid consistency bugs Zhang Boyang
2026-07-14 16:10 ` [PATCH 1/2] fstests: btrfs/348: test ambiguous generation handling on raid1 profile Zhang Boyang
2026-07-14 16:10 ` [PATCH 2/2] fstests: btrfs/349: test if latest tree-log is choosen at mount time " Zhang Boyang
2026-07-14 21:40 ` [BUG] two raid consistency bugs Qu Wenruo
2026-07-15 5:46 ` Zhang Boyang
2026-07-15 6:10 ` Qu Wenruo [this message]
2026-07-15 7:38 ` Zhang Boyang
2026-07-15 8:36 ` Qu Wenruo
2026-07-15 9:25 ` Zhang Boyang
2026-07-15 9:44 ` Qu Wenruo
2026-07-15 10:07 ` Zhang Boyang
2026-07-15 10:11 ` Qu Wenruo
2026-07-15 10:41 ` Zhang Boyang
2026-07-15 13:11 ` Alan Huang
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=5eaba968-b8b9-4705-9027-9169942e105f@suse.com \
--to=wqu@suse.com \
--cc=dsterba@suse.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=zhangboyang.id@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox