On 10/03/2013 04:23 AM, Wakko Warner wrote:

Please keep me in CC.

I compiled v3.3 to see if the problem was still there.  It is.  The problem. 
I setup an imsm array with 2 volumes.  a 200mb raid10 volume, and a raid5 on
the remaining space.  This was done from the bios.

mdadm detected the array and volumes ok, but the names are wrong.  the 200mb
was named EFI and the other was named ani.

/dev/md127 is the imsm container.
       126 is the volume ani. (This is about 7tb.  disks are 3tb each and
still initializing)
       125 is the volume EFI.

According to --examine /dev/md127,
[EFI] UUID is ad256dcf:38ff8fed:8c27647e:24f61d81
[ani] UUID is 9fe3c18a:0e9e2d4f:613456ca:b9989dcc

However --detail --export /dev/md125 shows the name as ani with UUID
ad256dcf:38ff8fed:8c27647e:24f61d81 and --detail --export /dev/md126 shows
the name EFI with UUID 9fe3c18a:0e9e2d4f:613456ca:b9989dcc.

I did manually bring these up using mdadm 3.2.5-5 (Debian).  I don't remember
the exact commands off the top of my head, but they should be in my history if
needed.

Do I understand correctly, this is the situation after bringing up the
array with mdadm 3.2.5, you are just looking at the state of affairs
with mdadm 3.3? If yes, I wouldn't expect any difference between the
output of mdadm 3.3 and 3.2.5. Both just reflect the current state of md
in the kernel (MD_DEVNAME is just the device name the array has under
/dev/md).

In order to see if your problem is fixed with mdadm 3.3, you must
assemble the array with 3.3 (and mdmon from 3.3 should be used as well).

Martin