[dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM
Laurence Oberman
loberman at redhat.com
Tue May 3 17:44:42 UTC 2016
----- Original Message -----
From: "Bart Van Assche" <bart.vanassche at sandisk.com>
To: "Laurence Oberman" <loberman at redhat.com>
Cc: "James Bottomley" <James.Bottomley at HansenPartnership.com>, "linux-scsi" <linux-scsi at vger.kernel.org>, "Mike Snitzer" <snitzer at redhat.com>, linux-block at vger.kernel.org, "device-mapper development" <dm-devel at redhat.com>, lsf at lists.linux-foundation.org
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 majordomo at vger.kernel.org
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
More information about the dm-devel
mailing list