RE: iSCSI: underrun with a check condition

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

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
>