On 06/17/2013 09:29 AM, Bart Van Assche wrote: > On 06/17/13 09:14, Hannes Reinecke wrote: >> On 06/17/2013 09:04 AM, Bart Van Assche wrote: >>> I agree that the value of fast_io_fail_tmo should be kept small. >>> Although as you explained changing the SCSI device state into >>> SDEV_BLOCK doesn't help for I/O that has already been queued on a >>> failed path, I think it's still useful for I/O that is queued after >>> the fast_io_fail timer has been started and before that timer has >>> expired. >> >> Why, but of course. >> >> The typical scenario would be: >> -> detect link-loss >> -> call scsi_block_request() >> -> start dev_loss_tmo and fast_io_fail_tmo >> >> -> When fast_io_fail_tmo triggers: >> -> Abort all outstanding requests >> >> -> When dev_loss_tmo triggers: >> -> Abort all outstanding requests >> -> Remove/disable the I_T nexus >> -> call scsi_unblock_request() >> >> However, if and whether multipath detects SDEV_BLOCK doesn't >> guarantee a fast failover; in fact is was only added rather recently >> as it's not a big win in most cases. > > Even if setting the state SDEV_BLOCK doesn't help much with > improving failover time, it still has the advantage over using > scsi_block_requests() that it can be overridden by a user via sysfs. > Argl. I meant scsi_internal_device_block(), not scsi_block_requests(). Of course.
So we're arguing a non-existing point :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
