Hi Mike, On Fri, Nov 12 2010 at 12:54pm -0500, Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx> wrote: > By not directly timing out the I/O but accelerating the timeout by a > factor. The value could be calculated as a percentage of the queue timeout > value for a default with the option of exposing a sysfs attribute > similar to fast_io_fail_tmo. The attribute could also provide a off > method which we do not have today and is my bad that we do not have one > (I posted the features patch to multipath but did not followup which > would have provided a off). You're referring to these patches: https://patchwork.kernel.org/patch/96674/ https://patchwork.kernel.org/patch/96673/ Do you have an interest in pursuing these further? In the near-term should we default to off (so introduce MP_FEATURE_ABORT_Q) -- given the current race which exposes corruption? Or are you now interested in accelerating the timeout? I'd need to review this thread in more detail to give you an opinion. But I do know that simply disabling dm-mpath's call to blk_abort_queue() enables some extensive path failure load testing to _not_ cause the list corruption that leads to a crash. Mike -- 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
