conditionally update uuids in the map file after Create()

The map file needs to be updated after adding the first member array to
an Intel metadata container.  The uuid for an imsm container uses the
->family_num field of the metadata.  This field is static, but is only
set after the first member array has been created.  Prior to this all
devices are free floating spares and do not have any information that
can identify specific container membership.  At Create() time we take
the uninitialized uuid from ->get_info_super() prior to updating the
metadata.  So the current result is:

# mdadm --create /dev/md/imsm /dev/sd[b-e] -n 4 -e imsm
# mdadm --create /dev/md/vol0 /dev/md/imsm -n 4 -l 0
# cat /var/run/mdadm/map
md126 /md127/0 3e03aee2:78c3c593:1e8ecaf0:eefb53ed /dev/md/vol0
md127 imsm 53d6f8b1:7a783f24:f30483c5:705c48c7 /dev/md/imsm
# mdadm -Ebs
ARRAY metadata=imsm UUID=589d2d2c:4221a54d:acb63c06:c3907f52
ARRAY /dev/md/vol0 container=589d2d2c:4221a54d:acb63c06:c3907f52
	member=0 UUID=57b89b63:5cd0eae1:17dd26b3:51cc78d4

So, before we write out the new metadata check to see if the member
array uuid has changed as a result of this addition.  If it has, update
its uuid in the map file and flag its parent container for updating.  In
support of updating the container uuid the semantics of
->write_init_super are changed to clear any metadata specific member
array cursors (e.g. ddf_super.currentconf or intel_super.current_vol)
such that a subsequent call to ->getinfo_super returns container
information.

Reported-by: Ignacy Kasperowicz <ignacy.kasperowicz@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>

0 files changed, 0 insertions, 0 deletions