01-173r0 SRP bidirectional residuals

Elliott, Robert Robert.Elliott at COMPAQ.com
Tue May 22 09:35:18 PDT 2001

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
Since SPC-2 says "The contents of the INFORMATION field is device-type or
command specific," any command set defining a bidirectional command should
be able to describe how the field should be filled for that command.

SPC-2 mentions that the INFORMATION field (which is four bytes long)
contains a LBA for direct-access devices.  Then it requires that the logical
block address must fit in two bytes or the INFORMATION field is invalid.
So, this seems pretty useless as currently defined.  According to 00-267r7,
the two-byte rule was added in SPC-2 revision 19 per comment 6.10.  The
resolution was concerned with > 2 TB LBAs, and should probably say "four
bytes" not "two bytes."  Ralph, can you slip this in with the public review

Something will have to be done to create a larger INFORMATION field in SPC-3
to support > 2 TB LBAs.  The solution should provide room so bidirectional
commands can specify two LBAs.

SPC-2 rev 19 section 7.20.2:
"The contents of the INFORMATION field is device-type or command specific
and is defined within the appropriate standard for the device type or
command of interest. Device servers shall implement the INFORMATION field.
Unless specified otherwise, this field contains:

a) the unsigned logical block address associated with the sense key, for
direct-access devices (device type 0), write-once devices (device type 4),
CD-ROM devices (device type 5), and optical memory devices (device type 7).
If the logical block address value cannot be represented in two bytes, the
VALID bit shall be set to zero;

b) the difference (residue) of the requested length minus the actual length
in either bytes or blocks, as determined by the command, for
sequential-access devices (device type 1), printer devices (device type 2),
processor devices (device type 3) and some direct access device commands,
except as defined for d) below. Negative values are indicated by two's
complement notation;

c) the difference (residue) of the requested number of blocks minus the
actual number of blocks copied or compared for the current segment
descriptor of an EXTENDED COPY command; or 

d) for sequential-access devices operating in buffered modes 1h or 2h that
detect an unrecoverable write error when unwritten data blocks, filemarks,
or setmarks remain in the buffer, the value of the INFORMATION field for all
commands shall be:
  a) the total number of data blocks, filemarks, and setmarks in the buffer
if the device is in fixed block mode (i.e., BLOCK LENGTH field of the MODE
SENSE block descriptor is non-zero and the FIXED bit of the WRITE command is
one); or
  b) the number of bytes in the buffer, including filemarks and setmarks, if
the device is in variable mode (i.e., the FIXED bit of the WRITE command is
For additional information on the use of the INFORMATION field by
sequential-access devices see SSC."

Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com

> -----Original Message-----
> From: Peter Johansson [mailto:PJohansson at acm.org]
> Sent: Monday, May 21, 2001 8:14 PM
> To: NCITS T10
> Cc: SBP-3
> Subject: Re: 01-173r0 SRP bidirectional residuals
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Peter Johansson <PJohansson at ACM.org>
> *
> At 05:48 PM 5/18/01, Elliott, Robert wrote:
> >I promised to review the bidirectional residual text in 
> FCP-2 and have 
> >written a proposal for how SRP should handle this in 01-173r0 (just
> >submitted for posting).  My recommendation is a bit 
> different than FCP-2 
> >or iSCSI, since SRP has better support for bidirectional 
> transfers. I 
> >recommend fixed DATA OUT and DATA IN residuals rather than 
> an OUT or IN 
> >residual (used as OUT for bi-di commands) along with a bi-di 
> IN residual.
> Rob (and anyone else),
> Your discussion in 01-173r1 is interesting, but I feel as if 
> something else is missing ...
> Doesn't this issue of TWO residuals have to be addressed in 
> SPC-2? For particulars, see the INFORMATION field in sense 
> data. Problem is, there's only one of it!
> Is work already underway to enhance SPC-2 (Ralph?) and I've 
> just missed the discussion? If not, how do protocol-dependent
> means, such as those proposed for FCP or SRP, help the hapless
> device driver writer that's expecting to 
> find out about underrun or overrun in sense data after CHECK 
> Regards,
> Peter Johansson
> Congruent Software, Inc.
> 98 Colorado Avenue
> Berkeley, CA  94707
> (510) 527-3926
> (510) 527-3856 FAX
> PJohansson at ACM.org
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list