SAM-3 proposal: ... Data-In and Sense Data sizes

Elliott, Robert (Server Storage) Elliott at
Wed Oct 30 16:43:38 PST 2002

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Server Storage)" <Elliott at>
Comments embedded...

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at] 
> Sent: Tuesday, October 22, 2002 4:04 PM
> To: t10 at
> Subject: Re: SAM-3 proposal: ... Data-In and Sense Data sizes
> Although I am referenced as the motivator for 02-404r0, "SAM-3
> Data-In Size and Sense Data Size for Execute Command", I cannot
> support the proposal as written for the following reasons:
> 1) There is no need for a Sense Data Size parameter because
>    the Sense Data format is self-defining with respect to
>    the number of sense data bytes present (see the ADDITIONAL
>    SENSE LENGTH field at fixed position byte 7 of the
>    Descriptor Sense Data Format). Adding a Sense Data Size
>    parameter only introduces new forms of inconsistent
>    (so might say erroneous) responses targets can generate.

[It is also self-defining for the fixed format and is required
to be no larger than 252 bytes in both formats.]

The self-defining format is only reliable if there are no errors 
when receiving the sense data.

Two kinds of problems could occur:
1. The target could return more bytes - extending past the end of 
the stated length.  SPI-5, FCP-2, SAS, SRP, and iSCSI have 
2-byte or 4-byte SENSE DATA LIST LENGTH fields in their 
RESPONSE IUs, so 16 KB to 4 GB could be transferred.  
What happens to the extra bytes?  

All implementations I've investigated ensure they don't overrun 
the size of the sense data buffer (usually provided by the
caller of Execute Command() - sometimes provided by the HBA's
low level driver itself).  

I haven't found any that parse the sense data format itself 
and truncate based on it.  They just blindly pass the data
up to the limit provided by the application client or their
own built-in limit.

2. The target could return fewer bytes than indicated - e.g.
0 or 4 bytes (not even getting past the ADDITIONAL SENSE
LENGTH field), or some amount less than the ADDITIONAL SENSE
LENGTH indicates.

How do the HBA and its driver communicate to the caller of
Execute Command() that this has occurred? 

Options include:
a) return a service response of SERVICE DELIVERY OR 
b) return a Sense Data Length indicating how much sense data 
is filled in;
c) require the application client to zero out the buffer,
and hope that zeros are enough to indicate unfilled data

If we mandate option a), the HBA and its driver must parse 
the ADDITIONAL SENSE LENGTH field to catch errors in the 
>8 byte range.  Option c) is unreliable.  Option b) - perhaps
paired with an optional option a) - seems the most robust.

> 2) The discussion of the proposed Data-In Size parameter states
>    "the initiator maintains a data count and returns the Data-In
>    Size directly to the application client." This represents a
>    profound departure from the principles of SAM-n. To the best
>    of my understanding, SCSI flat out does not work this way
>    and very few people want SAM-3 to go into the business of
>    specifying initiator behavior unless doing so is absolutely
>    necessary.

INQUIRY works on all protocols, either through residuals or 
through such calculation by the initiator HBA and its driver.
How else do you propose it works in a parallel SCSI HBA?

SAM-3 defines "application client" in these terms:
3.1.3 application client: An object that is the source of SCSI commands.
3.1.96 SCSI initiator device: A SCSI device containing application
clients and SCSI initiator ports that originate device service and 
task management requests to be processed by a SCSI target device.

SPC-3 defines "ALLOCATION LENGTH" (in as:
The ALLOCATION LENGTH field specifies the maximum number of 
bytes that an application client _has allocated_ for returned data.

To me, this means:
a) the application client owns the Data In Buffer
b) the application client calls Execute Command()
c) the application client passes a pointer to the Data In Buffer
as an input argument to Execute Command accompanied by a Data In 
Buffer Size, rather than receives a Data In Buffer with
implicit size as an output argument.

> 3) If a Data-In Size parameter were to be defined, the whole
>    objective of doing so should be to remove the following
>    paragraph from SAM-3 (top of pg 63 in r03):
>    "If a SCSI transport protocol supports random buffer access,
>    the offset and byte count specified for each data segment to
>    be transferred may overlap. In this case the total number of
>    bytes moved for a command is not a reliable indicator of
>    highest byte transferred and shall not be used by a SCSI
>    initiator device or SCSI target device implementation to
>    determine whether all data has been transferred."
>    However, 02-404v0 does not propose to remove this critical
>    statement.

Most read commands only make sense if data is delivered 
contiguously starting at the beginning of the Data In Buffer
(although not necessarily filling it to the end).  If data
is delivered in-order, then the residuals (in a RESPONSE
frame or calcuated by the HBA) indicate how much data is
valid.  This seems essential for commands like INQUIRY to

With relative offset, this data doesn't have to be delivered 
in order, and data might be overwritten multiple times.
At the end, though, if the logical unit knows that any gaps 
were not filled (picture some INQUIRY data with 4 bytes 
missing in the middle), it should return CHECK CONDITION
rather than GOOD status.  Although CHECK CONDITION doesn't
always mean the Data In Buffer is unusable, it does so for 
commands like INQUIRY.

For commands that:
a) return CHECK CONDITION status with a residual in the sense 
data indicating that some of the Data In buffer is valid
(e.g. READ LONG for block devices and READ for tape
devices); and
b) are run with relative offsets

the sense data residual has to be based on the lowest byte 
that wasn't successfully delivered.  This is the responsibility
of the logical unit; this residual is not protocol-specific.
The RESPONSE IU residual (or locally calculated equivalent)
is irrelevant given that a sense data residual is present.

Future commands could be invented that do not consider gaps
in the Data In Buffer to be an error.  The current sense
data residuals wouldn't work, but new ones could be invented.
An initiator's local data count doesn't help here, but neither 
does a residual in a RESPONSE IU.

Given the number of protocols with residuals in their 
response IUs, and that protocols without them also compute 
those same residuals, and that this information seems essential
for running commands like INQUIRY, I see no harm in communicating 
the Data In Size (or a residual) in Execute Command().

Data In Residual = Data In Buffer Size - Data In Size
Data In Size = Data In Buffer Size - Data In Residual

It doesn't matter whether Data In Residual or Data In Size 
is reported.]

Rob Elliott, elliott at
Industry Standard Server Storage Advanced Technology

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list