> [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. -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
