On 4/14/2010 3:18 PM, ceg wrote: > If I read your proposal correctly, running an array degraded would > always also "remove" the missing disk.
That is exactly what happens. When you give the go ahead to degrade the array, you fail and remove the missing disk. > This would imply to * break all the auto-re-add later feature of > mdadm --incremental (it also sports auto-read-only-until-write), even > though it is perfectly safe in the majority of cases (no conflicts). > * force users/admins to *allways* re-add manually after an array is > running degraded (this is not supporting hot-plugging, rather the > contrary) * make the perfectly safe re-addition of an outdated member > device ( i.e. older backup) look indistinguishable from re-adding a > member with conflicting changes (with data-loss!). The admin > (*allways* forced to --add manually) can not notice when the > operation will cause data loss. I suppose that you could avoid marking the missing disk as removed when degrading the array, then --incremental could try to add it again later automatically. If the disk has not been tampered with then it would be resynced, hopefully quickly with the help of the write intent bitmap. In this case where the other disk has also been modified, the conflict can be easily detected because the first disk says the second disk is failed, and the second disk says the first disk is failed. If the second disk was not also degraded then it would still show both disks are active and in sync. -- 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
