On Thu, 17 Feb 2011 12:21:05 +1100 linbloke <linbloke@xxxxxxxxxxx> wrote: > hansbkk@xxxxxxxxx wrote: > > I've only seen this problem with RAID1, but perhaps it applies to other levels. > > > > When adding a member partition to an array, the UUID of that partition > > gets set to that of the array (and all the other members) > > > > However, when fail/remove/zero-superblock 'ing a member back out of > > the array, the UUID gets left behind, along with the label and fs > > type. > > > > Ideally the partition would be left in a state as if it never had any > > filesystem at all on it, as when using dd /if=dev/zero and a fresh > > sfdisk. > > > > If this isn't possible, perhaps the zero-superblock option should > > trigger a reminder message to either zero the drive or re-format the > > partition? > > > > > I recall reading on this list that zero-superblock only zero's the first > superblock that it finds. It may be necessary to run mdadm > zero-superblock several times to remove all superblocks that may be on > the device from historical times. > The latest mdadm will zero all superblocks it can find. How I suspec the OP is actually talking about a 'filesystem' uuid rather than a 'raid' uuid... After all it is "along with the label and fs type". So: kansbkk: What makes you think the uuid is left behind? Knowing that will help know what uuid you are talking about. NeilBrown -- 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
