Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Zhang Boyang <zhangboyang.id@gmail.com>
To: Qu Wenruo <wqu@suse.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:38:23 +0800	[thread overview]
Message-ID: <8e02253e-2bd2-4ca1-8def-f91afaac4cd6@gmail.com> (raw)
In-Reply-To: <5eaba968-b8b9-4705-9027-9169942e105f@suse.com>

Hi,

On 2026/7/15 14:10, Qu Wenruo wrote:
> 
> 
> 在 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 think this is a very special variant of split brain problem. This bug 
can occur even if no degraded mounts are involved. All devices are 
presented to btrfs at every mounts. Personally I don't like to call this 
bug as a split brain problem because I think split brain should only 
related to degraded mounts.

> I strongly recommend to find out that thread and check if any of the 
> ideas are explored before and if they have their limits.
> 

I did read some of these threads. If split brain problems are solved, 
this bug can be solved as well. But I think fixing this particular bug 
is also beneficial.

>>
>> 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?
> 

Let me add another rule: always write superblocks of dirty devices after 
superblocks of (one of) latest devices are fully written.

Therefore, as long as there is no died device, there is at least one 
device not dirty so we can get golden data from it.

Of course performance may hit but we are safe.

> That kills the only chance to get the good metadata mirror.
> 

A recovery option can be introduced to disable the above policy.

> And this won't solve the split brain situation either.
> 

I'm not aiming to solve the split brain problems completely.

But waiting split brain problems to be solved is also a solution to this 
particular bug though.

>>
>> If dirty flag is detected, ask user to run a scrub. The dirty flag is 
>> cleared after a successful scrub.
>>
>>
>> Zhang Boyang
> 

Zhang Boyang

  reply	other threads:[~2026-07-15  7:38 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
2026-07-15  7:38       ` Zhang Boyang [this message]
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=8e02253e-2bd2-4ca1-8def-f91afaac4cd6@gmail.com \
    --to=zhangboyang.id@gmail.com \
    --cc=dsterba@suse.com \
    --cc=fdmanana@kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.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