> 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. > Yeah...I guess since this is already the case where REC is being rejected, so probably not much point doing internal retry, rather better rely on scsi-ml.
yi _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
