So, its been a while since this issue resurfaced, but I feel it needs to be put to rest.
Are we really sure we should fix this? http://marc.info/?l=linux-raid&m=127068416016382&w=2 "I don't think there is anything practical that could be changed in md or mdadm to make it possible to catch this behaviour and refuse the assemble the array... Maybe mdadm could check that the bitmap on the 'old' device is a subset of the bitmap on the 'new' device - that might be enough. But if the devices just happen to have the same event count then as far as md is concerned, they do contain the same data." -- Neil Brown I happen to agree with Neil, that this isn't something mdadm or the md driver should be capable of. If nothing else, it is a feature request, and not a High issue. I've changed the ISO testing guide to advise booting with both disks between each boot with a disconnected disk. Other than that limited ISO testing scenario, when is this actually affecting users? I do also like Billy Crook's random number addition idea here: http://marc.info/?l=linux-raid&m=127073871318005&w=2 But that sounds a lot like a feature request. So, what I'm suggesting is that this bug should actually be set as a Wishlist, not High importance, because while it could lead to data corruption, so could putting my disks in the microwave. Booting a RAID1 with 1 disk, then immediately with the other, is just not something a normal user would do, it just came up because of the instructions on the test case itself. -- 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs