On 08/05/2018 01:35 PM, donotcare@xxxxxxxxxxx wrote: > Thank you for the replies. I guess I realize that a mismatch in the absence of a known hardware failure is difficult to resolve. I thought that maybe with raid6, the raid6check util would be able repeatedly do parity checks with/without various stripes in a systematic way to determine which one was most likely to be errant. But at least in my case (see below) it did not. > > Anyway, I figured out the answer to the other part of my question. The location of the mismatches reported by md in the syslog is in bytes (not sectors). And the stripe size is the same as the chunk size, at least in my arrays: 512KiB. [trim /] > So unfortunately it did not point to a suspect device. > > I tried to see what file was there, so not knowing exactly how to do this, i divided the ext4 4K block size into the byte offset of the first mismatch: > > 2742887048 / 4096 = 669650.158203125 > > So i guess it's in the middle of block 669650. > > debugfs: icheck 669650 > Block Inode number > 669650 299761790 > > debugfs: ncheck 299761790 > Inode Pathname > 299761790 /blah/my/file/name.ext > > Does that seem right? Yes. > To fix, I was thinking: > > 1) unmount /dev/md1 > 2) echo repair > /sys/block/md1/md/sync_action > 3) fsck -f /dev/md1 > 4) mount /dev/md1 > 5) rm -f /blah/my/file/name.ext > 6) # restore /blah/my/file/name.ext from backups > > would this work? Yes. > Does the repair sync_action fix mismatches on a non-degraded array? Yes. > Given that I plan to delete the file, I guess it doesn't matter how the mismatch is fixed? Correct. Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
