RE: Data in SCSI Response or SCSI Data

["Douglas Otis" <dotis@sanlight.net>]

Julo,

The "bridging patch" is to reconcile iSCSI expected length against SCSI CDB
length.  For a definition see FCP FCP_RESID.  I could not find any
information relating to this in the SAM specification as suggested.  It is
not directly related to SCSI nor is it directly related with SCSI non-error
residual.  By combining status with the Read PDU 0x45, the ability to "oops"
on perhaps a substantial transfer is removed.  Once started, there is no
means to report a problem with the transfer.  This combining of status has
limited merit as a series of smaller reads carries this added residual and
status as wasted overhead in all but the last transfer.  The Read PDU moves
the point of processing status optionally to the beginning or middle of the
command rather than at the end as in all other cases.  This READ PDU implies
perfection in transport as it predicts the future with no end of transfer
confirmation.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> julian_satran@il.ibm.com
> Sent: Saturday, September 09, 2000 12:57 AM
> To: ips@ece.cmu.edu
> Subject: RE: Data in SCSI Response or SCSI Data
>
>
>
>
> Overrun/Underrun situations are a "bridging patch" from the block count
> model
> used by the "classical SCSI" (perhaps matched by some buffering model in
> some transports) and the byte count model specified by SAM.
>
> As a command has a byte count associated to it and the CDB has a block
> count
> the resulting inconsistency (if any) is reported in overrun/underrun byte
> count delivered by
> the target.
>
> As for a non-zero residual being an error, as far as I can read it - it is
> today a target decision
> and except for some legacy devices most do not report it as an error ( a
> far cry from
> the 360 channel days where it was an error unless explicitely
> requesting it
> not to be by
> a bit in the command).
>
> Julo
>
> "Douglas Otis" <dotis@sanlight.net> on 08/09/2000 21:50:16
>
> Please respond to "Douglas Otis" <dotis@sanlight.net>
>
> To:   "Robert Snively" <rsnively@Brocade.COM>, "Stephen Bailey"
>       <steph@cs.uchicago.edu>, ips@ece.cmu.edu
> cc:    (bcc: Julian Satran/Haifa/IBM)
> Subject:  RE: Data in SCSI Response or SCSI Data
>
>
>
>
> Bob,
>
> Thanks, that helps an understanding of this PDU 0x45.  If iSCSI is to copy
> FCP then it should send a response structure as FCP and not one or two and
> use it according to FCP.  Undefined information of what some consider SCSI
> values cause variants in use.  I have not seen tape drives use Good Sense
> residual but vary in how Check Sense residual is presented.  If
> iSCSI is to
> copy FC, then why deviate on response symmetry?  At least this provides an
> easier bridge.  Iterative read operations will carry unused values to be
> examined and opens the door for further variants.  Status presented prior
> to
> data must then ensure sequence without end confirmation.
>
> Doug
>
> > -----Original Message-----
> > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > Sent: Friday, September 08, 2000 9:20 AM
> > To: 'Douglas Otis'; Stephen Bailey; ips@ece.cmu.edu
> > Subject: RE: Data in SCSI Response or SCSI Data
> >
> >
> > In FCP, because FC is a multi-protocol environment that may have
> > drivers independent of the SCSI drivers, an actual buffer allocation
> > was transmitted independently of the SCSI command.  Both overrun
> > and underrun indicators and a residual are returned.  They are
> > protocol related, not SCSI related.
> >
> > There are cases where incorrect length indications are provided
> > in the SCSI model for both under-run and over-run cases, but they
> > are rare and typically associated with legacy tape drive programs.
> >
> > Bob
> >
> > >  -----Original Message-----
> > >  From: Douglas Otis [mailto:dotis@sanlight.net]
> > >  Sent: Wednesday, September 06, 2000 6:26 PM
> > >  To: Stephen Bailey; ips@ece.cmu.edu
> > >  Subject: RE: Data in SCSI Response or SCSI Data
> > >
> > >
> > >  Steph,
> > >
> > >  Although a logical use of a residual, I can not see where it
> > >  is defined
> > >  should the allocation length be greater than the returned
> > >  length.  Should
> > >  the allocation be less than the response, this is a Check
> > >  Condition and the
> > >  residual is defined.  It would seem a residual in a case
> > >  with adequate
> > >  allocation is not interesting or defined.  Do you know where
> > >  this mechanism
> > >  you describe is defined?  In normal use, without a Check
> > >  Condition such
> > >  information is not returned to the application.
> > >
> > >  Doug
> > >
> > >  > -----Original Message-----
> > >  > From: owner-ips@ece.cmu.edu
> > >  [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > >  > Stephen Bailey
> > >  > Sent: Wednesday, September 06, 2000 3:45 PM
> > >  > To: ips@ece.cmu.edu
> > >  > Subject: Re: Data in SCSI Response or SCSI Data
> > >  >
> > >  >
> > >  > > When do you get GOOD status and residual counts on a read?
> > >  > What is causing
> > >  > > the target to get the length wrong?
> > >  >
> > >  > One example is an INQUIRY command.  The inquiry data length is
> > >  > target-specific.  Typically the CDB allocation length (and
> > >  DL) are set
> > >  > to some arbitrary large value (0xff), and the target sends back
> > >  > everything it has.  The transfer ends with success status.
> > >  >
> > >  > There can certainly be transfer residual and no SCSI error status.
> > >  >
> > >  > Steph
> > >  >
> > >
> > >
> >
>
>
>
>