On Thu, 2013-07-04 at 10:01 +0200, 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; I think this sounds reasonable; I need to make sure I understand the new behaviors of the code to be sure. I'm also concerned about Vu's bug report at this late stage; I'll be watching for its resolution -- hopefully in time for inclusion. -- 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
