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. -- Chris Murphy -- 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
