On 4/19/2010 1:10 PM, ceg wrote: > (Between reboots I haven't seen too random/changing device > reordering anyway. Mostly the enumeration seems to stay the same if > nothing is rewired. I'd consider the hot-plugging order much more > arbitrary, and even less worth of committing to the meta-data.)
You just made my point. The hot plugging case is the best example here. If I plug in one disk and make some changes, then unplug it, plug in the other disk, and make some changes to it, in the future I don't want which set of changes appears to depend on which disk I plug in first. As soon as both disks are plugged in and the conflicting changes are detected, you must record that in the metadata. > But would you see it as necessary to ensure a consistent uncorrupted > array and closing this bug? I think it is enough if mdadm will only Very much so. > assemble the first part attached regularly. It may be good however if > mdadm would assemble any conflicting parts as extra devices (normally > md128 and up) so the parts are accessible for inspection, can be > compared, manually merged etc. No need to do that automatically, this is where manual intervention comes in. Once mdadm has rejected one of the disks and the admin notices, he can easily ask mdadm to move it to another array by itself to be mounted, inspected, merged, etc. > Updating the metadata would prevent working with and switching > between concurrent versions in a hot-plugging manner. Think of the > use-case of segmenting a (non-root fs) data-array into two halves in > order to do some major refactoring. (This is like keeping a snapshot > by using only part of the mirror.) If that is the intent, then the user needs to manually remove one disk from the array and set it aside or add it to a separate array if they wish. If we /accidentally/ fork the array, we need to set the conflicting array aside and notify the user that they need to sort the situation out manually. We avoid making the situation any worse than it already is by updating the metadata. -- 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