Summary: | sys-fs/mdadm: --zero-superblock should log what metadata version it clears | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jason Mours <jason.mours> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | CC: | alexander, nitr0 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jason Mours
2013-11-12 19:17:51 UTC
1. 3.3.1 is not in portage yet 2. This is not a bug, but a feature. I you give a name to an array (--name=zebra0), then the array is accessible by both 'standard' name /dev/mdXX and by /dev/md/${name} And 0.90 metadata format does not support names. See man page. Sorry, I meant 3.3-r1 , not 3.3.1-r1. I know it's a feature that adds the /dev/md/#NAME. The real ARRAY is defined in /dev as /dev/md126 or /dev/127 and /dev/md/#NAME is a soft link to the real array... the --name=arrayname add a name like : mymachine:arrayname in metadata, I know this is a 1.2 feature... I did not use the --name= or -N when using -e 0.90. : So to continue with metadata 1.2, I partitioned the ARRAY, fdisk or mdadm DID NOT create all the soft links i.e. /dev/md127 -> /dev/md/zebra0 /dev/md127p1 -> /dev/md/zebra0p1 /dev/md127p2 -> *missing* I created the softlink, reboot erased it /dev/md127p3 -> /dev/md/zebra0p3 /dev/md127p4 -> *missing* like p2 So I decided to go more stock and use the recommended /dev/md0 which does not create the /dev/md/#NAME soft links. BUT I was unable to change this in the metadata, which is the reason for filing the bug. After stopping the array and zero-superblock the drives, I recreated the ARRAY using -C /dev/md0 ... assembled the array, partition, format, mount, migrate some data & all looks good until I reboot. The /dev/md0 become /dev/md127 again and /dev/md/zebra0 reappears...missing softlinks and all. So, I fixed my issue by reverting to metadata 0.90...& I apologize if I was unclear filing the bug. I did everything I know to strip any information at the beginning of the drives. "I have tried mdadm --zero-superblock, mkswap, fdisk and using the hardware raid controller to pop the disk label off , to erase the metadata / superblock." Which lead me to discover that mdadm metadata 1.2 places it's superblock 4K in, as apposed to right at the begining for all metadata < 1.2. It looked like mdadm --zero-superblock didn't wipe the stored metadata 1.2 which lies 4K in on the platters. I'm using metadata 0.90, which I hear is superior anyways, so I don't plan on reverting back to 1.2 *** Bug 489682 has been marked as a duplicate of this bug. *** (In reply to Jason Mours from comment #0) > I have tried mdadm --zero-superblock, mkswap, fdisk and using the hardware > raid controller to pop the disk label off , to erase the metadata / > superblock. From "man mdadm": [...] The old metadata will remain on the devices, but will appear older than the new metadata and so will usually be ignored. The old metadata (or indeed the new metadata) can be removed by giving the appropriate --metadata= option to --zero-superblock (In reply to Thomas D. from comment #5) > (In reply to Jason Mours from comment #0) > > I have tried mdadm --zero-superblock, mkswap, fdisk and using the hardware > > raid controller to pop the disk label off , to erase the metadata / > > superblock. > > From "man mdadm": > > [...] The old metadata will remain on the devices, but will appear older > than the new metadata and so will usually be ignored. The old metadata > (or indeed the new metadata) can be removed by giving the appropriate > --metadata= option to --zero-superblock Now I understand, but shouldn't mdadm --zero-superblock default to the metadata-1.2 as it does on the -C? Sorry, the RAID is live and I can't test this out to verify, but I don't doubt you. RTFM! seems like a simple request to send upstream: when a device is cleared successfully, have it log the metadata version it cleared out |