SAM-3 proposal: ... Data-In and Sense Data sizes
Elliott, Robert (Server Storage)
Elliott at hp.com
Wed Oct 30 16:43:38 PST 2002
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at compuserve.com]
> Sent: Tuesday, October 22, 2002 4:04 PM
> To: t10 at t10.org
> 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
How do the HBA and its driver communicate to the caller of
Execute Command() that this has occurred?
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
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 220.127.116.11) 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 18.104.22.168. (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
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
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
Rob Elliott, elliott at hp.com
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 t10.org
More information about the T10