On Thu, May 31, 2012 at 10:42 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > If there are errors on the bus, the chances are the devices are missed > by the initial discover and appear later anyway, so neither approach is > foolproof. I like the how long is the user prepared to wait approach vs > how long does it take to complete error recovery simply because mostly > if the device doesn't appear within that time it is a bug (or a hardware > configuration problem). I agree that the "how long is the user prepared to wait" approach is optimal. But there is no way for the user to express "I want to be fast and safe" i.e. wait just the minimum time the subsystem needs to complete an initial scan. Outside of building the module into the kernel to take advantage of the built-in wait_for_device_probe() in prepare_namespace(). That minimum time varies based on configuration. I've watched dracut fail raid assembly even though the driver had not returned 'done' from ->scan_finished(). A generous timeout would fix that, but now you've overshot what the kernel was prepared to call the initial discovery window. > Conversely, if you think of the usual case: the root device appears long > before bus probing finishes, so by only waiting for root, we assist the > fast boot process. Yes, it sucks to do "wait world" when you just need a subset, but I'm only saying to do the global wait in the case where the raid metadata expects all devices to be present and we are about to degrade the array for the first time. So in the "all devices appear case" or the "array already marked degraded case" we wouldn't need to wait and boot would proceed soon as root is able to be assembled. ...but maybe that is my answer. A generous timeout incurred only when that first degraded event happens? I don't know just makes me uncomfortable that userspace has no visibility into all the machinery that makes wait_for_device_probe() work in the built-in case. But maybe that is because prepare_namespace() is not free to be as expressive as an initramfs and can only use the big hammer. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
