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

Reply via email to