Bill Nottingham wrote:
Dan Williams (dan.j.williams@xxxxxxxxx) said:
Well this only happens for containers (so BIOS raid using mdadm, the new
intel stuff) and I've talked to Dan Williams about this (who has done
most of the imsm mdadm code) and he considered this normal behaviour ?
Incremental mode will try to run an array as soon as it is feasible. The
container is runnable with any number of disks so we need to hold off
starting the container until all member disks and hot spares have been
added to the container. This option also covers the case where stale
disks are initially added to the container at the start of discovery. We
want to wait until discovery completes as it may find newer metadata on
later members that identifies stale disks and prevents them from being
re-activated.
So it is blocking too early assembly.
Sure, but if it actually has all member disks and hot spares, I don't
see why it wouldn't start then, even if --no-degraded is passed.
The challenge posed by the metadata format is that there is no
container-association information for spares. In other words we never
know how many spares are potentially missing so we can only rely on
'discovery complete' as an event to stop waiting for disks.
However, re-adding hot-spares that missed the initial assembly can be
something that gets pushed off to another udev rule. I agree it would
be nice if mdadm -I --no-degraded could start the array when it looks
like all the disks have arrived. In the end this would not eliminate
the need to do a final "mdadm -I" after discovery completes as we need
to commit to degraded arrays at some point.
--
Dan
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
