RE: to iScsi from Scsi, quickly please

["Martin, Nick" <Nick.Martin@compaq.com>]

Pat,

I will attempt this one because I think I understand it.

The O (overrun) and U (underrun) bits indicate (redundantly) the sign of
the residual you describe for Scsi2.  O (overrun) indicates not all the
data was used (residual contains actual minus expected).  U (underrun)
indicates that the data supplied is less than expected (residual
contains expected minus actual).  Data is transferred in only one
direction by each command except for bi-directional commands.  For
bi-directional commands only, two residual fields and two pairs of bits
(ou and OU) are used to indicate data transfer result in each direction.

All this is detected and reported from the target's point of view.  The
potential overrun or underrun are detected between the iSCSI session and
the SCSI layer within the target node, and reported back to the
initiator via iSCSI protocol.

Any failure to transfer the expected number of bytes between the
initiator and the target iSCSI sessions is handled within TCP and/or
iSCSI.

Any failure of the iSCSI session to transfer the expected number of
bytes into or out of initiator memory is an internal matter within the
initiator.

A common or expected case would involve a variable length read.  The
expected data transfer length is in this case better described as a
maximum data transfer length or initiator buffer allocation size.  The
actual transfer length is determined by the length of the data available
from the logical unit within the target.  The U bit (set) and the
residual count report the expected (max) data transfer length minus the
actual data length available from the logical unit.  The number of data
bytes transferred from the target to the initiator by iSCSI will be the
number of bytes available.

In summary, these residuals report differences between the length in the
original request and the length processed by the target logical unit.
The iSCSI session is expected to always transfer the correct number of
bytes over the network between initiator and target data buffers.  There
are no additional residual counts reported.

Someone will correct the precise semantics I should have used.  I hope
this explanation answers your question and can be clearly understood.

Thanks,
Nick
> -----Original Message-----
> From: Pat LaVarre [mailto:p_lavarre@yahoo.com]
> Sent: Monday, January 28, 2002 5:47 PM
> To: ips@ece.cmu.edu
> Cc: p.lavarre@ieee.org
> Subject: to iScsi from Scsi, quickly please
> 
> 
> > http://www.ietf.org/internet-drafts/
> > draft-ietf-ips-iscsi-10.txt
> > Expires August 2002
> > 1.3.5  Expected Data Transfer Length
> > 1.4.4  Residual Count
> > 1.4.5  Bidirectional Read Residual Count
> 
> Would someone here be happy to quickly sketch for me
> how iScsi defines measurable residues?  (I'm newly
> subscribed here.)
> 
> I ask because legacy Scsi work once taught me to
> always measure two residues between command out and
> status in:
> 
> 1) Expected minus actual count of data bytes that
> moved in, negative only if the host of the device
> discards data in.
> 
> 2) Expected minus actual count of data bytes that
> moved out, negative only if the host of the device
> fabricates data out.
> 
> To understand ips-scsi-10, I gather I should have a
> different model in mind?
> 
> At first glance, the ips-scsi model doesn't seem as
> general as, for example, Scsi2 is on paper.  In
> ips-scsi I think I see more provision for unexpected
> data moving in that for unexpected data moving out?
> 
> Clue me in, anyone?
> 
> Thanks in advance, cluelessly yours.    Pat LaVarre
> <p.lavarre@ieee.org>
> 
> P.S. The web links that brought me here included:
> 
> http://www.usenix.org/events/fast/tech.html
> http://www.almaden.ibm.com/cs/storagesystems/iscsi/index.html
> http://www.ece.cmu.edu/~ips/
> http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html
> http://www.pdl.cmu.edu/cgi-bin/htsearchIPS resid
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Great stuff seeking new owners in Yahoo! Auctions! 
> http://auctions.yahoo.com
>