Comment 33 for bug 557429

> Once
> the situation is detected, it needs to be noted

Right, this is important especially in cases where segmentation has happened unintentionally. That is why I wanted mdadm to fail on conflicting changes without --force, not auto-sync and emit an event (email, beep, notification, whatever configured).

> so that further reboots
> will not decide to use the other disk. Pick one, and stick with it
> until the admin sorts things out.

Bear in mind that mdadm --incremental is handling more than reboots, and segmenting the array can be intentional by the admin/user.

> Updating the metadata is needed to prevent further flip-flopping.

(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.)

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 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.

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.)