On 2016-06-26 00:33, Chris Murphy wrote: > On Sat, Jun 25, 2016 at 12:42 PM, Goffredo Baroncelli > <kreij...@inwind.it> wrote: >> On 2016-06-25 19:58, Chris Murphy wrote: >> [...] >>>> Wow. So it sees the data strip corruption, uses good parity on disk to >>>> fix it, writes the fix to disk, recomputes parity for some reason but >>>> does it wrongly, and then overwrites good parity with bad parity? >>> >>> The wrong parity, is it valid for the data strips that includes the >>> (intentionally) corrupt data? >>> >>> Can parity computation happen before the csum check? Where sometimes you >>> get: >>> >>> read data strips > computer parity > check csum fails > read good >>> parity from disk > fix up the bad data chunk > write wrong parity >>> (based on wrong data)? >>> >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/btrfs/raid56.c?id=refs/tags/v4.6.3 >>> >>> 2371-2383 suggest that there's a parity check, it's not always being >>> rewritten to disk if it's already correct. But it doesn't know it's >>> not correct, it thinks it's wrong so writes out the wrongly computed >>> parity? >> >> The parity is not valid for both the corrected data and the corrupted data. >> It seems that the scrub process copy the contents of the disk2 to disk3. It >> could happens only if the contents of disk1 is zero. > > I'm not sure what it takes to hit this exactly. I just tested 3x > raid5, where two files 128KiB "a" and 128KiB "b", so that's a full > stripe write for each. I corrupted devid 1 64KiB of "a" and devid2 > 64KiB of "b" did a scrub, error is detected, and corrected, and parity > is still correct.
How many time tried this corruption test ? I was unable to raise the bug systematically; in average every three tests I got 1 bug.... [....] -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
