Re: [PATCH] fix random failures in shell/integrity.sh

Dne 07. 08. 25 v 16:07 Mikulas Patocka napsal(a):
> 
> 
> On Thu, 7 Aug 2025, Stuart D Gathman wrote:
> 
>> On Wed, 6 Aug 2025, John Stoffel wrote:
>>
>>>>>>>> "Mikulas" == Mikulas Patocka <[email protected]> writes:
>>>
>>>> The problem is that the raid1 implementation may freely choose which leg
>>>> to read from. If it chooses to read from the non-corrupted leg, the
>>>> corruption is not detected, the number of mismatches is not incremented
>>>> and the test reports this as a failure.
>>>
>>> So wait, how is integrity supposed to work in this situation then?  In
>>> real life?  I understand the test is hard, maybe doing it in a loop
>>> three times?  Or configure the RAID1 to prefer one half over another
>>> is the way to make this test work?
> 
> If you want to make sure that you detect (and correct) all mismatches, you
> have to scrub the raid array.
> 
>> Linux needs an optional parameter to read() syscall that is "leg index"
>> for the blk interface.  Thus, btrfs scrub can check all legs, and this
>> test can check all legs.  Filesystems with checks can repair corruption
>> by rewriting the block after finding a leg with correct csum.
>>
>> This only needs a few bits (how many legs can there be?), so can go in
>> the FLAGS argument.
> 
> I think that adding a new bit for the read syscalls is not a workable
> solition. There are so many programs using the read() syscall and teaching
> them to use this new bit is impossible.

I believe the idea of the test is to physically check the proper leg is 
reporting an error.

So instead of this proposed patch - we should actually enforce reading leg 
with lvchange --writemostly to select the preferred leg among other legs.

The bigger question is though - that user doesn't have normally a single 
workable leg - as  'reading' is spread across all legs - thus when one leg 
goes away - it could have happen that other legs have also some 'errors' 
spread around...


Zdenek