RE: iSCSI: underrun with a check condition

["Julian Satran" <satran@haifasphere.co.il>]

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
>