On 2015-08-20 12:44, Chris Murphy wrote:
IIUC, the checksumming is done on each part of the block written (in which case it's really easy to see which is bogus. There's also the fact that if one of the parities is wrong, but the other isn't, the parity block that is wrong is probably faulty (although this isn't a 100% guarantee).On Wed, Aug 19, 2015 at 9:43 PM, Russell Coker <russ...@coker.com.au> wrote:On Thu, 20 Aug 2015 11:55:43 AM Chris Murphy wrote:Question 1: If I apply the NOCOW attribute to a file or directory, how does that affect my ability to run btrfs scrub?nodatacow includes nodatasum and no compression. So it means these files are presently immune from scrub check and repair so long as it's based on checksums. I don't know if raid56 scrub compares to parity and recomputes parity (assumes data is correct), absent checksums, which would be similar to how md raid 56 does it.Linux Software RAID could recreate a mismatched block from RAID-6 parity but doesn't do so. It could be that a block was changed correctly but didn't get the parity data written so such "correction" would be reverting a change. So Linux Software RAID only regenerates parity for a scrub and makes both disks have the same data for RAID-1.https://www.kernel.org/pub/linux/kernel/people/hpa/raid6.pdf Discussion starts in section 4 on page 7. The relevant part I'm confused about is on page 8, " once the faulty drive has been identified" doesn't clarify a mechanism to determine which data drive is corrupt. Iti seems without that knowledge, it's not possible to reconstruct. Further, should there be two corruptions, however unlikely, reconstruction causes a third corruption. So it's a bit risky.
In any case though, in normal operation, md raid6 isn't checking parity. It always assumes the data chunks are valid unless the drive itself returns a read error. For scrub repair, it assumes data is correct and writes new parity, which is different than with a raid1 scrub repair where there's something of a random (?) assumption which mirrored chunk is correct and the other(s) are overwritten. I don't even know that with n-way mirroring this scrub assumes majority rules.
Based on my own testing, it doesn't handle that sanely.
smime.p7s
Description: S/MIME Cryptographic Signature
