Yet another of an endless (but not too frequent fortunately) stream of "wildly optimistic" messages to this mailing list... > Would the resync just copy all the data from the "good" drive > back to the "failed" drive? This seems to me quite "imaginative" based on the dream that resync has psychic powers. > For diagnostic purposes, it would actually be a lot more > informative to compare the two drives and see if there really > is data corruption on one of them or not. This seems to me "wildly optimistic" that when two blocks differ it is possible in the general case to determine whether one (and which one) or both are "corrupted". > Is there a way to do that? 'man cmp' may show a way to "compare the two drives". > If I were to demonstrate that the data are in sync, I would > want to reassemble without resync. "Fantastic logic". > Also, in my situation, since for now I'm just using a pair of > external drives, I could easily imagine accidentally trying to > assemble the array when one of the drives is powered down. > Then this situation would arise again without faulty hardware. This may be based on the "amazing insight" that differences in content and event counts are the same as data corruption. > Prudence notwithstanding, I do think there are valid cases for > reassembling this array without resync. I believe that you think that but I also believe the manual when it says "Use this only if you really know what you are doing"; because many MD users may not have the level of skills and insight about RAID that you think you have, MD is designed to protect users by default from their own "amazing optimism", especially users that haven't read yet: https://raid.wiki.kernel.org/index.php/RAID_Recovery https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID > If there's a way to do that, I'd still like to know. 'man mdadm' may show a way to assemble "without resync". -- 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
