> > > >Looked into patch description: > > > >After scrubbing dev3 only: > >0xcdcd (Good) | 0xcdcd | 0xcdcd (Bad) > > (D1) (D2) (P) > > > >So the Parity stripe (P) always get replaced by exact content of D1/D2 (data-stripe) > >or by random data? > > Neither. it's just XOR result of D2(never changed, 0xcdcd) and old D1(wrong, > 0x0000). > 0xcdcd XOR 0x0000 = 0xcdcd > > So you got 0xcdcd, bad result. > > If you corrupt D1 with random data, then parity will be random then. > > >If it always get replaced by exact value from either > >D1 or D2. I think current script can be modified to detect that bug. If parity gets > >replaced by random value, then it will the make task more difficult. > > Not hard to detect. > As the content is completely under your control, you know the correct parity > value, and you can verify it very easy. > version-3 of this script calculates exact data/parity location, instead of dumping data and searching locations. Tested with upto 8MB file, from the output all 128 data-stripes and 64 parity stripe location seems fine. It constantly hit the parity bug with the script. If the script gets accepted, will add slightly other corruption variants likes: - corrupt all even stripe (D2,D4..) - corrupt all odd stripe (D1,D3..) - corrupt all parity stripes - corrupt all both data stripe (D0 & D1) and expect error message (Cover above cases for RAID6) thanks. Cheers. Lakshmipathi.G -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
