Re: Request for review of Linux iSCSI driver version 4.0.0.1

[Mike Anderson <andmike@us.ibm.com>]

Clay Haapala [chaapala@cisco.com] wrote:
> On Wed, 3 Dec 2003, Mike Anderson outgrape:
> 
> > Clay Haapala [chaapala@cisco.com] wrote:
> >> 
> >> Naveen, is it intended that the iSCSI driver retry when the 0B/4705
> >> is detected, or will that sense code and COMMAND ABORT be passed up
> >> to the SCSI layers for retry?
> >> 
> >> James, et al, do the SCSI layers retry on COMMAND ABORT?
> >> 
> >> I don't believe the SCSI layers retry on HARDWARE ERROR -- this is
> >> a difference between how Solaris and Linux operate, for example,
> >> unless I am misunderstanding or have obsolete information.  --
> > 
> > scsi_check_sense will return NEEDS_RETRY for:
> > 	- ABORTED_COMMAND
> > 
> > 	- NOT_READY and UNIT_ATTENTION under the expecting_cc_ua and
> > 	becoming ready case.
> > 
> > 	- MEDIUM_ERROR
> > 
> > If the allowed count has not been exceeded the command will be
> > retried.
> > 
> > -andmike
> 
> A couple of related SCSI (not necessarily iSCSI) questions:
> 
> "If the allowed count has not been exceeded" - The first two commands
> after a connection has been estabilished will fail with
> Unit_Attention. What if that first command then also gets a crc error
> (Aborted_command)?  Will the retry count be large enough?
> 

The sd upper level driver sets the allowed value to SD_MAX_RETRIES
(5). In your above example it would be retried. In theory a scsi command
could have been through the retry path SD_MAX_RETRIES-1 times prior and 
would not be retried.

> Does the retry also apply to tape?  Without proper tape error
> recovery, retrying the command could result in duplicate records
> written to tape.
> 

The tape upper level drivers set there retries to 0 for read and write
operations.

andmike
--
Michael Anderson
andmike@us.ibm.com