Re: iSCSI: underrun with a check condition

[Andre Hedrick <andre@linux-ide.org>]

Santosh,

In effect you are stating the initiator has no need to help the
personality drivers above the HBA it is faking?  Does this imply that
hints returned via SCSI status are to be ignored?  If so this means the
initiator is exclusively a pass through HBA, and this makes some logic.

This also can mean if any initiator attempt to use both portions of the
information returned in a response, it may not be compliant to the RFC ?

Eddy, you added a few wrinkles to think a new direction, thanks!

Andre Hedrick
LAD Storage Consulting Group


On Mon, 17 Feb 2003, Santosh Rao wrote:

> Eddy,
> 
> You're right in that the transport driver is supposed to set the u/o/resid
> fields and it must set this for all scsi status' anytime the number of bytes
> transferred is not equal to the number of bytes requested.
> 
> This issue was discussed in the context of a previous UNH plugfest in
> Aug 2002 and here is the outcome of that discussion :
> http://www.pdl.cmu.edu/mailinglists/ips/mail/msg11510.html
> 
> The initiator scsi llp may check the u/o/resid fields, indpendent of the 
> scsi status returned. SCSI status is not required to be parsed/interpreted 
> by the initiator scsi llp. The scsi status checks belong in the initiator 
> scsi ulp layer.
> 
> Thanks,
> Santosh
> 
> 
> > 
> > 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.
> > 
> > The only thing we need to know in iSCSI is the intent of paragraph 10.4.1.
> > 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
> > > 
> > 
> 
> 
> -- 
> **************************
> Santosh Rao
> HP-UX SCSI Team,
> Hewlett Packard, Cupertino
> **************************
>