Comment 52 for bug 557429

> [auto-removing]
> prevents you from continuing to flip flop which disk you are using
> after they have been forked, and thus making things worse.

And, this is a program thinking it knows better than the user, mdadm
--incremental should not do that. If you continue to do that after you
have been informed you probably do it intentionally, and mdadm should
not interfere.

I have provided dist-upgrades and refactoring usecases of non-root filesystem array as use-cases that swich between versions. And Neil also told you about backup schemes.

> The array is already broken up.

For conflicting changes to occur, 1) arrays need to be running degraded,
which should only happen automatically with arrays required to boot when
parts are missing during boot. Then 2) the missing part has to reappear
and 3) be run degraded also while 4) the previously remaining part is
removed, and then 5) both parts have to be present again.

Aside from this, hot-plugging/connecting parts of an array to any
machine should never run it degraded.

> Resyncing will destroy data. If you
> want to rescue that data you must move the other disk to its own array
> so you can mount it.

With hot-pluggable devices you don't have to. You should just need plug
them into your system and they should get mounted. So once an array is
run degraded, if you plug just the part you want, it should get mounted,
done.

> After you have rescued any data, then you can
> drop it back into the original array and it will sync.

With hot-pluggable devices you should just need to plug both parts, the
one you want to keep first. Then "mdadm --stop <md-auxilarily>" and
"mdadm --add <md-to-keep> <members-with-conflicting-changes> --force",
done.