Comment 20 for bug 557429
Revision history for this message
| ceg (ceg) wrote Re: booting out of sync RAID1 array fails with ext3 (comes up as already in sync) | #20 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
>> mdadm should not just sync the disk slower to appear to the first one, because the parts
>> are inconsistent!
>
>This statement does not make sense.
Oh, right, yes. To put it better: They should not be synced if they "contain conflicting changes"
If I read the case originally reported, the drives actually weren't manually --removed, just disconnected during power-down. If mdadm starts to distinguish between missing/removed, the disk missing at boot time will probably still just be marked missing, same if it has actually failed, I guess.
But more generally: By forcing to manually re-add removed disks, while mdadm is not refusing to sync conflicting parts of an array, we only make re-adding the data-loss inducing action. Manually re-adding and syncing *might* (I am not so sure) assemble/resync a consistent array, but will lead to discard one part of the conflicting changes in the array (data-loss).
(Though, from what was written it does sound valid to me now, not to auto-readd "removed" disks, if "missing" disks are auto-readded.)
To prevent data-corruption, I think mdadm is required to detect conflicting changes. No matter if disks re-added automatically (like in having a auto synced back-up in the docking station/external disk) or re-added manually.