On 07/04/13 10:01, Bart Van Assche wrote:
On 07/03/13 20:57, David Dillow wrote:
And I'm getting the strong sense that the answer to my question about
fast_io_fail_tmo >= 0 when dev_loss_tmo is that we should not allow that
combination, even if it doesn't break the kernel. If it doesn't make
sense, there is no reason to create an opportunity for user confusion.
Let's take a step back. I think we agree that the only combinations of
timeout parameters that are useful are those combinations that guarantee
that SCSI commands will be finished in a reasonable time and also that
allow multipath to detect failed paths. The first requirement comes down
to limiting the value fast_io_fail_tmo can be set to. The second
requirement means that either reconnect_delay or fast_io_fail_tmo must
be set (please note that a reconnect failure changes the state of all
involved SCSI devices into SDEV_TRANSPORT_OFFLINE). So how about
modifying srp_tmo_valid() as follows:
* Add an argument called "reconnect_delay".
* Add the following code in that function:
if (reconnect_delay < 0 && fast_io_fail_tmo < 0 && dev_loss_tmo < 0)
return -EINVAL;
(replying to my own e-mail)
A small correction to what I wrote above: a reconnect failure only
causes the SCSI device state to be changed into SDEV_TRANSPORT_OFFLINE
if the fast_io_fail mechanism has been disabled.
Bart.
--
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
