Re: [BUG] two raid consistency bugs

在 2026/7/15 18:55, Zhang Boyang 写道:
> Hi,
> 
> On 2026/7/15 16:36, Qu Wenruo wrote:
> 
>> 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.
>>
> 
> Technically the runtime burden is small because generation mismatch is 
> rare. If no generation mismatch is detected, no device will be marked 
> dirty and no runtime burden is involved. On the other side, if 
> generation mismatch is detected, you always want to run a scrub to 
> resync your array.
> 
>> 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.
>>
> For maintenance burden, yes, there is maintenance burden. So I'm here to 
> discuss which way to fix this bug is proper.
> 
>> 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.
> 
> This can be a solution, at the cost of one failing drive will render 
> entire raid array unavailable.
> 
> Personally I like the idea of turning metadata trees into merkle trees 
> (so I wrote it first). But since you are the maintainer, I will let you 
> decide which way is appropriate‌.

I'm not the maintainer, I just default to not trust ideas/features from 
unproven contributors, especially when the idea/feature is not simple.

Especially considering the increased patches generated by LLMs.


So my suggestion is, if you really want to do long-term contributions, 
stop coming up with fancy ideas, start from basics like doing proper 
fstests runs with various combinations, report real bugs and fix simple 
ones by yourself.

Earn your name first then consider fancy ideas.

> 
> 
> Zhang Boyang
>