Roberto Ragusa wrote on Mon, Sep 28, 2020: > >I could imagine using kpartx to script a solution to (1) above, skipping > >over the md headers. Some kind of shim may be needed to fool the kernel > >to see a different UUID for each source volume so they can be mounted > >simultaneously without md. > > The kernel can do it, on a fully operational array. > > cat /sys/block/md0/md/sync_action > echo check > /sys/block/md0/md/sync_action > cat /sys/block/md0/md/sync_action > > then > > cat /proc/mdstat > cat /sys/block/md0/md/mismatch_cnt There are two problems to that: - you won't ever know what file or even block was mismatched (I've just read that despite check being a 'check', on if it encounters a mismatch it will correct either copy? in there just now : https://serverfault.com/a/854123 But I'm pretty sure that wasn't the case in the past, at least not when there is not enough parity to automatically guess a 'correct' answer, so I'm not sure about that one) There are patches to print the mismatched sector in dmesg e.g. this question has one : https://unix.stackexchange.com/questions/266432/md-raid5-translate-md-internal-sector-numbers-to-offsets But it's still a pain to use and figure which files are impacted (disclosure: I wrote that answer) - some raid array vendors don't initially sync the array, on the basis that the filesystem should never access data it didn't write first, so during the monthly scrub you get zillions of mismatches every single time... Just to save a day at start of operation :( Obviously won't be a problem for everyone, but this is known to happen. So ultimately it's all good if your mismatch_cnt stays at 0 but in case of problem you're in for a longer ride. -- Dominique _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
