Comment 38 for bug 557429
Revision history for this message
| Phillip Susi (psusi) wrote Re: [Bug 557429] Re: array with conflicting changes is assembled with data corruption/silent loss | #38 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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.