Working with mdadm for the first time constructing a RAID0 stripe, ran into the following problem. I had originally constructed, the stripe using the following command with two untouched drives. : bash / # mdadm -C /dev/md/zebra0 -l 0 --name=zebra0 --raid-devices=2 /dev/sda /dev/sdb : This creates a /dev/md/zebra0 and /dev/md126, partitioned /dev/md/zebra0p1 & /dev/md126p1. Now I want to stop and destroy the array, then rebuild it as : bash / # mdadm -C /dev/md0 -l 0 --name=zebra0 --raid-devices=2 /dev/sda /dev/sdb : It then show /dev/md0 but when a query is sent via mdadm --examine --scan, the old ARRAY is listed as /dev/md/zebra0. My /etc/mdadm.conf is still stock template with no entries. mdadm --detail --scan show the new ARRAY as /dev/md0. When I reboot, the ARRAY is rebuilt as /dev/md127 & /dev/md/zebra0. Adding mdadm --detail --scan >> /etc/mdadm.conf, after rebuilding the array as /dev/md0, fixes that problem as the system assembles the array as /dev/md0, but mdadm --examine --scan shows the artifact ARRAY still as /dev/md/zebra0. 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. Long story short, TOO LATE!, I had to use the -e 0.90 switch to specify the 0.90 standard and now my mdadm --examine --scan is reporting ARRAY /dev/md0. Destroying and rebuilding the array with metadata 1.2 brings back the artifact as the ARRAY /dev/md/zebra0 is re-listed. Looking further into it, metadata 1.2 places the superblock 4K in... older version of metadata place it at the beginning. I think this is what's not addressed. Reproducible: Always
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
