> 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.) -- array with conflicting changes is assembled with data corruption/silent loss https://bugs.launchpad.net/bugs/557429 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
