RE: iSCSI: underrun with a check condition

["Jackson, Tom" <Tom.Jackson@emulex.com>]

Tape drives don't work this way.  On tape devices, the block size is not
necessarily fixed.  The initiator may not know the block size for a read
ahead of time.  The initiator often depends on the sense data to determine
what command to issue next.

-----Original Message-----
From: Andre Hedrick [mailto:andre@linux-ide.org]
Sent: Monday, February 17, 2003 12:35 PM
To: Eddy Quicksall
Cc: Julian Satran; 'Santosh Rao'; '"Ips@Ece.Cmu.Edu"'
Subject: RE: iSCSI: underrun with a check condition


On Mon, 17 Feb 2003, Eddy Quicksall wrote:

> At the initiator, it would be up to the transport driver whether or not to
> pass these fields to the ULP depending on the status value.
> 
> At the target, the SCSI layer should not be knowledgeable of the expected
> transfer length because with parallel SCSI that is not passed on the wire.
> So the setting of these fields should be up to the transport driver.

You ask for X you had better get X.
If you do not get X, but X - N, the initiator (general terms now) is
expected to ignore the results and retry.  If the retry fails then the
target (general terms now) is expected to issue a failed media status.
Now how all these relate to what iSCSI sends or recieves is up the the
implimentation.

The SCSI does know the length if it a data in/out phase.
The attached CDB describes this fully.

Are you stating a position of the response?

> The only thing we need to know in iSCSI is the intent of paragraph 10.4.1.

Gurr, now I have to go re-read to finish the second half of the reply.


Cheers,

--andre

> Since that paragraph does not specify which status's it applies to, it is
> assumed that it applies to ALL statuses. I just wanted to be sure that was
> then intent. My examples were just to stir up some thinking on the issue.
> 
> Eddy
> 
> -----Original Message-----
> From: Julian Satran [mailto:satran@haifasphere.co.il] 
> Sent: Monday, February 17, 2003 7:36 AM
> To: 'Andre Hedrick'
> Cc: 'Santosh Rao'; 'Eddy Quicksall'; '"Ips@Ece.Cmu.Edu"'
> Subject: RE: iSCSI: underrun with a check condition
> 
> The whole discussion is at the border between SCSI and iSCSI.
> All I said is not that iSCSI will not process the command but rather
> that SCSI LLP will
> Know that it does not have to do anything (almost - it has to look if
> the command is a sense or an inq) but send the status. iSCSI will act as
> usual. My assumption was that the flags and residual length are
> generated by SCSI as it is the one relating byte counts with CDB
> information/device information
> 
> Regards,
> Julo
> 
> 
> -----Original Message-----
> From: Andre Hedrick [mailto:andre@linux-ide.org] 
> Sent: 17 February, 2003 14:11
> To: Julian Satran
> Cc: 'Santosh Rao'; 'Eddy Quicksall'; '"Ips@Ece.Cmu.Edu"'
> Subject: RE: iSCSI: underrun with a check condition
> 
> 
> 
> Julian,
> 
> This implies the Status Sequence Number and the Expected Command
> Sequence Window shall not be adjust by the target, period.  Thus the
> initiator would timeout and fail the command, or follow through on
> appropriate ERL states until it decays to a logout-login.
> 
> So I agree the target does not care about U/O bits for the most part in
> this case, but acknowledging the command regardless of direction will
> corrupt data to platter (for future expected reads) or generate a
> dereferrence null pointer from the filesystem or requesting application.
> 
> This assumes the command was a data in or out phase.
> If it was a task management command, I suspect things would become fuzzy
> for error faults from the requesting application.
> 
> Other than the HBA and/or Spindle to fault, why would one expect the
> target to no process the command?  Obviously one could have a net/fabric
> transport problem and miss the command, but there are other rules to
> protect both sides unless the target supports out of order command.
> 
> Regardless which end of the transaction on target one picks, a failure
> to process will jam the command and status sequence numbers some how.
> 
> The only other issue addressed by Eddy is the case of partial
> completions of the request.  Nowhere in the drafts or now RFC does it
> permitt such events without the U_bit being set.  Any target that
> permits an overrun based on the allocated data lenght requested is sure
> to explode, if it does not then the initiator will have a problem with
> the F_bit missing. Unless the target sets the F_bit proper in the
> stream.  One then encounters the problem of dumping the remainder if the
> O_bit is not set with the (effectively early F_bit).
> 
> If I have rambled and failed to describe the points clearly, please let
> me know.
> 
> Cheer,
> 
> Andre Hedrick
> LAD Storage Consulting Group
> PyX Technologies, Inc.
> 
> On Mon, 17 Feb 2003, Julian Satran wrote:
> 
> > Santosh,
> > 
> > For any check condition in which the target did process the command 
> > this is the expected behavior. The example Eddy gave involves a target
> 
> > that due to ACA or BUSY does not initiate processing the command.
> > In this case the target provider does not HAVE TO set the U/O bits
> (and
> > the associated values).
> > The relevant piece of information appears in SAM2 5.3.2 that indicates
> > that status precedence.
> > Obviously a target MAY set the U/O bits although  I doubt that an
> > initiator will look them up.
> > 
> > Regards,
> > Julo
> > 
> > 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf 
> > Of Santosh Rao
> > Sent: 16 February, 2003 23:28
> > To: Eddy Quicksall
> > Cc: "Ips@Ece.Cmu.Edu (ips@ece.cmu.edu)"
> > Subject: Re: iSCSI: underrun with a check condition
> > 
> > 
> > Eddy,
> > 
> > Yes, anytime the amount of data transferred does not match the data 
> > transfer length specified, the target must set the U bit or O bit, 
> > depending on whether an underflow or overflow occurred.
> > 
> > A recovered error check condition may be returned as the response to a
> 
> > scsi command which was processed to completion. The recovered error 
> > indicates that a previous command completed successfully with some 
> > recovery action by the device server and the sense data provides 
> > additional details on that previous command.
> > 
> > The current command on which a recovered error check condition was 
> > returned may have been processed to completion, or experienced some 
> > underflow or overflow. This information must be conveyed by the target
> 
> > in the iscsi scsi response pdu using the appropriate fields to 
> > describe the underflow or overflow.
> > 
> > Thanks,
> > Santosh
> > 
> > 
> > > Should the target set the U bit when it gives a check condition to a
> > > data-in command?
> > >  
> > >  
> > > Eddy
> > 
> 

Andre Hedrick
LAD Storage Consulting Group