Re: MDADM 3.3 broken?

[Martin Wilck <mwilck@arcor.de>]

On 11/20/2013 03:30 AM, NeilBrown wrote:

>>>> mdadm --examine --scan
>>> ARRAY metadata=ddf UUID=7ab254d0:fae71048:
>>> 404edde9:750a8a05
>>> ARRAY container=7ab254d0:fae71048:404edde9:750a8a05 member=0
>>> UUID=5337ab03:86ca2abc:d42bfbc8:23626c78
> 
> This shows that mdadm found a container with the correct UUID, but the member
> array inside the container has the wrong uuid.
> 
> Martin: I think one of your recent changes would have changed the member UUID
> for some specific arrays because the one that was being created before wasn't
> reliably stable.  Could  that apply to David's situation?

I am confused. AFAIL, my patch bedbf68a first introduced subarray UUIDs
for DDF. I don't understand how this mdadm.conf could have worked with
mdadm 3.2.x.

But you are right, I had to make 7087f02b later that changed the way
subarray UUIDs were calculated. This would hurt people who created their
mdadm.conf file) with stock 3.3 and updated to latest git later.

> David: if you remove the "UUID=" part for the array leaving the
> "container=.... member=0" as the identification, does it work?

I second that. David, please try it. I'd also appreciate "mdadm -E
/dev/sdX" output for all the RAID disks.

Martin