>> All would be clearer if * mdadm -E would report "missing" instead of >> removed (which sounds like it really got "mdadm --removed") > > There already exists a faulty state. It might be appropriate to use that
This and the detection process sounds reasonable to me. I am not sure how much sense auto-removing a confilicting part from an array makes from the user side. As the order in which devices appear can be random or not, I would rather like mdadm to refrain from doing any metadata updates based on that, if it is not necessary. With mdadm patched to detect and report conflicting changes and not to sync conflicting changes without --force, it should protect from unaware data-loss and corruption and always provide a coherent state, consisting of the first or (maybe intentionally even) only part that appears from an array. A coherent mdadm way of informing the user about the appearance of conflicting changes (after a run degraded event) to would probably be to emit a "conflicting changes" mdadm --monitor event. If mdadm --incremental would auto-remove a part with confilicting changes, it might not remove the correct part the user may actually --remove. But the situation would look very similar as if some admin had actually --removed something. Possibly wrongly suggesting to the admin that its a simple and safe matter of re-adding, while he actually needs to manually reverse the auto-remove operation, to prevent critical data- loss. -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
