I'd suggest to consider the following option about whether to assemble segments known to contain conflicting changes or not:
AUTO -SINGLE_SEGMENTS_WITH_KNOWN_ALTERNATIVE_VERSIONS > That's because it DOESN'T break hot-plugging. I have explained why. You have the right to think that, obviously we disagree on that point. You may often think you explained something while I miss explanations really, especially for what I explicitly asked for. It seems you consider segments being available one at a time, then on some incidence eventually together, and then one at a time again later would indicate a not-mainly-theoretical failure type and it should be handled by always auto-removing all but the first segment on the incidence. (So they won't get auto assembled anymore.) Let's conclude this is OK, for part of the users. (Mostly those that want to be sure and manage their arrays issuing commands by hand.) But it does pose a problem if you want to support managing array segments by just plugging disks and occasionally commanding simple sync directives (eventually just by right clicking on the segments showing up on the desktop). > > from this moment on the raid system will not keep the > > system running as designed, and like it did before both segments > > came up together once. (You would change/break behavior.) > > Yes, and this change is entirely intentional because if you don't do > this, then you can unintentionally continue to further diverge the two > disks without noticing, You'd have to miss or ignore quite e few notifications to not notice. Notice is given as soon as the first degradation occurs. So the admin should know something is going on and usually take action already way before the incidence happens. At last upon the second notification, when the same array is run degraded again, he can know it has split into segments with conflicting changes (even if the message may (currently) not be explicit about it). Note however that even if I think a failure showing this type of behavior seems more fictional than users intentionally segmenting the array before upgrades and such, I can very well relate to those not wanting to configure mdadm.confs AUTO option at all (i.e. on servers) just to be sure nothing happens behind their backs. And just so to set "AUTO -SINGLE_SEGMENTS_WITH_KNOWN_ALTERNATIVE_VERSIONS" in order to disable hot-plugging for segments with alternative versions. That's what settings are for and what can make all happy. -- 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
