----- Original Message ----- From: "Bart Van Assche" <[email protected]> To: "Laurence Oberman" <[email protected]> Cc: "James Bottomley" <[email protected]>, "linux-scsi" <[email protected]>, "Mike Snitzer" <[email protected]>, [email protected], "device-mapper development" <[email protected]>, [email protected] Sent: Monday, May 2, 2016 6:28:16 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM
On 05/02/2016 12:28 PM, Laurence Oberman wrote: > Even in the case of the ib_srp, don't we also have to still run the > eh_timeout for each of the devices that has inflight requiring error > handling serially. This means we will still have to wait to get a > path failover until all are through the timeout. Hello Laurence, It depends. If a transport layer error (e.g. a cable pull) has been observed by the ib_srp driver then fast_io_fail_tmo seconds later the ib_srp driver will terminate all outstanding SCSI commands without waiting for the error handler to finish. If no transport layer error has been observed then at most (SCSI timeout) + (number of pending commands + 1) * 5 seconds later srp_reset_device() will have finished terminating all pending SCSI commands. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Bart OK, Yes, that lines up with my testing here with Qlogic and Emulex. I am about to test srp but I need to add some jammer code first. The link down and other interruptions will always be fast. Its always going to be the black-hole events that are troublesome. Thanks Laurence -- dm-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/dm-devel
