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 <mpato...@redhat.com> 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
