Neil Brown wrote: > On Wednesday May 9, bs@xxxxxxxxx wrote: >> Neil Brown <neilb@xxxxxxx> [2007.04.02.0953 +0200]: >>> Hmmm... this is somewhat awkward. You could argue that udev should be >>> taught to remove the device from the array before removing the device >> >from /dev. But I'm not convinced that you always want to 'fail' the >>> device. It is possible in this case that the array is quiescent and >>> you might like to shut it down without registering a device failure... >> Hmm, the the kernel advised hotplug to remove the device from /dev, but you >> don't want to remove it from md? Do you have an example for that case? > > Until there is known to be an inconsistency among the devices in an > array, you don't want to record that there is. > > Suppose I have two USB drives with a mounted but quiescent filesystem > on a raid1 across them. > I pull them both out, one after the other, to take them to my friends > place. > > I plug them both in and find that the array is degraded, because as > soon as I unplugged on, the other was told that it was now the only > one. And, in truth, so it was. Who updated the event count though? > Not good. Best to wait for an IO request that actually returns an > errors. Ah, now would that be a good time to update the event count? Maybe you should allow drives to be removed even if they aren't faulty or spare? A write to a removed device would mark it faulty in the other devices without waiting for a timeout. But joggling a usb stick (similar to your use case) would probably be OK since it would be hot-removed and then hot-added. David - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
