>> 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. ** Summary changed: - booting out of sync RAID1 array fails with ext3 (comes up as already in sync) + booting out of sync RAID1 array comes up as already in sync (data-corruption) -- booting out of sync RAID1 array comes up as already in sync (data-corruption) 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
