Hello Dan,

On Fri, Nov 8, 2013 at 11:02 PM, Dan Williams [off-list ref] wrote:

On Fri, Nov 8, 2013 at 5:45 AM, Francis Moreau [off-list ref] wrote:

quoted

Hello Lukasz

On Wed, Nov 6, 2013 at 3:08 PM, Dorau, Lukasz [off-list ref] wrote:

 [...]

quoted

If you created a RAID array with mdadm, it would work correctly - recovery would
start.

Nope, I've got an identical behaviour if the array is created by mdadm (v3.3).

It should really work either way.  I gave it a shot with:

mdadm - v3.3-30-gf33a71f - 31st October 2013
mdadm - v3.2.5 - 18th May 2012

...and it seems ok with loop devices, so something more fundamental is wrong.

mdmon is in charge of finding new devices in the container and adding
them to the member arrays.  Can you confirm that mdmon is running when
the disk is failing to be added?

The IMSM format is sensitive to disk serial numbers, I'm curious if
your virtual disks are specifying unique serial numbers for your
devices?  In my above tests with loopback devices I am using
IMSM_DEVNAME_AS_SERIAL=1 for debug purposes you might try that as
well.

I think I found something.

In my current settings, when mdadm creates a new RAID array with
foreign metadata, it starts mdmon by using systemd throught the
mdmon@.service. However in that case the new mdmon process doesn't see
the IMSM_NO_PLATFORM environment variable set because process started
by systemd are executed in a clean env.

To verify this, I created the array again by calling mdadm with
MDADM_NO_SYSTEMCTL env variable set and it worked as expected. I also
tested by using systemd and by adding "Environment=IMSM_NO_PLATFORM=1"
in the unit file and it worked too.

WDTY ?

Thanks
-- 
Francis