On Thu, October 15, 2009 5:38 am, Darius S. Naqvi wrote: > On Wed, 14 Oct 2009, Darius S. Naqvi wrote: > >> I.e., it seems that the ioctl invoked by --fail doesn't directly set >> up the device to be ready for --remove, but some other kernel thread >> completes that state change. I'm wondering if it could be the case >> that when the system is very, very busy, it could take long enough for >> that kernel thread to run that it would cause what I see, i.e., >> --remove fails with EBUSY, even though I've already waited about 20 >> seconds for the device to be ready to be removed. If this is so, what >> shall I do? Here are the options I can think of: > > Sorry to reply to my own posting. It turns out that in this case, > I've only waited 2.5 seconds. This may affect the probability of my > hunch being correct. 2.5 seconds certainly seems more believable than 20 seconds. Waiting for the kernel thread to run is not the only cause for delay. If there are any pending IO requests, you have to wait for all of those to complete before the device can be removed from the array. As error handling can take an arbitrarily long time, there can be an arbitrary delay between a device being marked faulty and it being able to be removed from the array. So probably the best bet is simply to wait and retry as you are doing. If I were to make it more deterministic, I would probably allow you to 'poll' or 'select' on the sysfs file /sys/block/mdX/md/dev-YYY/slot and once that becomes 'none', the device can be removed. NeilBrown > > -- > Darius S. Naqvi > dnaqvi@xxxxxxxxxxxxxxx > http://www.datagardens.com > -- > 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 > -- 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
