RE: iSCSI: underrun with a check condition

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

Julian,

I would not assume the boundary to be SCSI|iSCSI, I would only assume
Spindle|iSCSI.  As a few may have decide to only continue to promote the
true of all storage, "It is all a LIE".  Whatever the spindle or physical
media used to store or retrieve the content, only has to commit all the
"LIES" associated to reporting back to iSCSI.  Obviously this is a target
side view of the world.

Targets should never send an overrun to iSCSI, period.
Targets should never send an underrun to iSCSI, period.

Nowhere does it allow for the target to break up the full command
requested from the initiator and issue multiple returns for the same
command.  All a target can do is thumbs up or down the command for data.

It is the initiator who is responsible for resegmenting the command.

Targets have the prosition of the Drive Makers.  In all the T-Committees,
drives (aka targets) specifiy a means to address the device or you get an
aborted command.  It is not the job of the drive/target to clean up the
mess initiators make.  This is clear throughout the RFC that targets get
to nuke anything it does not like.

So with this in mind, if the drive/target ignores the initiator it is the
initiator's problem to figure out what the issues are and the current
status.  A smart initiator can work around a broken or weak target.  A
smart target can give hints, but there is not much a target do.

Erm, I think I went south and the brain oops more of an opinion.

Cheers,

--andre

On Mon, 17 Feb 2003, Julian Satran wrote:

> 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
> > 
>