Re: [BUG] two raid consistency bugs

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‌.


Zhang Boyang