Re: [BUG] two raid consistency bugs

在 2026/7/15 17:08, Zhang Boyang 写道:
> 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.

I do not agree.

You're introducing more and more code just to handle some very specific 
corner cases.

E.g. for your particular case, you will need a very specific write 
situation. You're introducing a feature that is very hard to hit under 
most situations, but we will always bear the burden.

I am not even sure if you'll still contribute in the next 5 years, thus 
I won't bet my 5 cents on that this feature will be properly maintained.


To me, if you really bother this particular situation for whatever 
reason, just introduce a special harden mount option, that any 
barrier/super block write failure will mark the fs error.

That will be a much safer bet than any of your proposal.