Comment 56 for bug 557429

> whether some other component automatically invokes mdadm
> to move the second disk to a brand new array, or the admin has to by
> hand, I don't really care.

You are probably not aware enough that all udev/hotplug magic for raid
is within mdadm --incremental. I.e. in the future it will even set
up blank disks inserted into DOMAINs defined in mdadm.conf as spares etc.

As a last overall note: Maybe remember again that raid systems are
designed to keep your machine running as long as possible up until
no redundancy is left.

When the redundancy is increased again it can happily resync if possible. When the
system runs without redundancy on different array segments one at a
time, they can not be synced until redundancy has been restored.

In this case conflicting changes may occur, it's the nature of a "only one at a time" failure
that the changes will not allways be available, but raid can keep the
system running until the cause is identified and fixed, while no data is
really lost.

If it happens that both segments get available with
conflicting changes, one needs to be chosen (first one is already
there). But if you update the metadata on this occasion (disabling one segment),
from this moment on the raid system will not keep the
system running as designed, and like it did before both segments came up
together once. (You would change/break behavior.)