On 10/17/2010 9:32 PM, Zou, Yi wrote: >> >> On 10/17/2010 09:54 PM, Mike Christie wrote: >>> On 10/14/2010 10:43 AM, John Fastabend wrote: >>>> Use the rport value for rec_tov for timeout values when >>>> sending fcp commands. Currently, defaults are being used >>>> which may or may not match the advertised values. >>>> >>>> The default may cause i/o to timeout on networks that >>>> set this value larger then the default value. To make >>>> the timeout more configurable in the non-REC mode we >>>> remove the FC_SCSI_ER_TIMEOUT completely allowing the >>>> scsi-ml to do the timeout. This removes an unneeded >>>> timer and allows the i/o timeout to be configured >>>> using the scsi-ml knobs. >>>> >>> >>> Does fcoe commands timeout more frequently than other transports? I like >> >> Oh yeah, I meant to write if cmds timing out is common and it is also >> common that if you just retry the IO it succeds then you do not want to >> return DID_BUS_BUSY for the timeout case. This will cause unnecessary >> multipath failovers/failbacks due to DID_BUS_BUSY being fastfail able >> when the fast fail transport bit is set. >> >> I actually thought the 10 sec internal timeout was done so eventually >> (eventually == meaning someone meant to add code but did not get around >> to it yet) you could retry internally several times before the scsi cmd >> timer fires and that starts the scsi eh. > I thought SCSI_ER_TIMEOUT was for the internal retry, but no idea why 10s > and no way to tune it as John pointed out. Taking it out would help both > mpio as well as i/o w/ a rather long path delay. > > yi
I don't see much advantage to doing any internal error recovery. IO timeouts should be infrequent enough that the slow abort handling is good enough. If we eventually need to handle aborts better we can look to fix the scsi eh as you suggested. With this approach the I/O timeout value can be tuned through the normal scsi interfaces to accommodate various networks. Thanks, John. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
