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.
Bart.
--
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
