At 01:31 PM 11/27/2012 +1100, NeilBrown wrote: >> >> Appears then that 'mdadm' may not >> check the superblock to see if the >> drive came from a different array >> and should not be overwritten, and >> instead prefers to just zap it. > >Correct. When you ask mdadm to --add device to >an array, that is what it will do. If the >metadata looks particularly good it might do a >re-add for you, but if not it will just erase >it and write some more. Thank you very much for the confirmation. >> Can anyone confirm or deny the >> possibility? I can manually run >> an --examine and check the array >> name as a precaution when rotating >> drives if 'mdadm' doesn't perform >> the check. Want to avoid inserting >> a offsite drive in the wrong array. > >We might be able to make "mdadm -I" do what >you want ... find out which array >it "should" be a member of and auto-add it. >But that will currently fail for an >out-of-date member with no bitmap. > Actually I was thinking more about 'mdadm' not destroying an old-but-good mirror copy from a different array. So if I accidently pull the wrong drive out of the safe deposit box, then 'mdadm' would refuse to zap and re-label the drive on an attempt to insert it in the wrong array. An explicit --zero-superblock would have to be run before a drive could be re-used in any array with a different name. Not a big deal though. I will be sure to --examine all rotate-in drives carefully before --grow --add'ing them. -- 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
