RE: iSCSI: underrun with a check condition

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

Tom:

Just has I clicked send, I remembered about the error generators from the
depths below ground.  All they do is generate errors and noise during
standard operations along with CDR's for the most part.  So I stand
corrected on the O/U-bit point.  Given how much more cost effective cheap
spindles are today, I still wonder why tape media still exists.

Again, I cheated the answer by only thinking of fixed disk media.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Mon, 17 Feb 2003, Jackson, Tom wrote:

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