Comment 27 for bug 557429

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.