Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 491108

Summary: sys-fs/mdadm: --zero-superblock should log what metadata version it clears
Product: Gentoo Linux Reporter: Jason Mours <jason.mours>
Component: [OLD] Core systemAssignee: 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
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
Comment 1 Alexander Tsoy 2013-11-14 20:32:32 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}
Comment 2 Alexander Tsoy 2013-11-14 20:34:27 UTC
And 0.90 metadata format does not support names. See man page.
Comment 3 Jason Mours 2013-11-15 00:20:38 UTC
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
Comment 4 Amadeusz Żołnowski (RETIRED) gentoo-dev 2013-12-11 06:30:13 UTC
*** Bug 489682 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Deutschmann gentoo-dev Security 2013-12-11 14:05:41 UTC
(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
Comment 6 Jason Mours 2013-12-11 21:53:06 UTC
(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!
Comment 7 SpanKY gentoo-dev 2013-12-16 05:35:45 UTC
seems like a simple request to send upstream: when a device is cleared successfully, have it log the metadata version it cleared out