On Wed, 2013-07-03 at 20:24 +0200, Bart Van Assche wrote: > On 07/03/13 19:27, David Dillow wrote: > > On Wed, 2013-07-03 at 18:00 +0200, Bart Van Assche wrote: > >> The combination of dev_loss_tmo off and reconnect_delay > 0 worked fine > >> in my tests. An I/O failure was detected shortly after the cable to the > >> target was pulled. I/O resumed shortly after the cable to the target was > >> reinserted. > > > > Perhaps I don't understand your answer -- I'm asking about dev_loss_tmo > > < 0, and fast_io_fail_tmo >= 0. The other transports do not allow this > > scenario, and I'm asking if it makes sense for SRP to allow it. > > > > But now that you mention reconnect_delay, what is the meaning of that > > when it is negative? That's not in the documentation. And should it be > > considered in srp_tmo_valid() -- are there values of reconnect_delay > > that cause problems? > > None of the combinations that can be configured from user space can > bring the kernel in trouble. If reconnect_delay <= 0 that means that the > time-based reconnect mechanism is disabled.
Then it should use the same semantics as the other attributes, and have the user store "off" to turn it off. 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. -- 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
