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

Ralph Weber ralphoweber at compuserve.com
Wed Oct 30 19:31:28 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
Rob,

The exposition below appears to be confusing implementation with
architecture.

Adding a SENSE LENGTH parameter recommends (or maybe requires)
that SCSI Transport Protocols include equivalent information
in their Response IUs. This may, in due course, affect how
HBAs are designed but from a SAM perspective that is nowhere
near as interesting as the requirements placed on targets as
a result of the necessary requirements in the SCSI Transport
Protocols.

As for SENSE LENGTH options, the most straight forward option
appears to have been overlooked. SPC-3 should be modified to
require that when allocation length is greater than 8, at least
8 bytes of Sense Data shall be returned.

The problems with the DATA-IN LENGTH proposition are similar
to those with SENSE LENGTH. In this case, however, I take the
absence of suitable information in the SAS Response IU as an
indication that the current thinking in the industry that
provision of a DATA-IN LENGTH parameter is inappropriate.

When it was pointed out to me that SAS does not support DATA-IN
LENGTH several weeks ago, I knew the idea of adding a DATA-IN
LENGTH parameter in SAM-3 was dead.

As for the matter of Inquiry data, like Sense Data the format
of Inquiry data is self describing, and the definition of
Inquiry data requires that the length field be included,
to whit:

  "The standard INQUIRY data (see table 56) shall contain
  at least 36 bytes."

All the best.

.Ralph

"Elliott, Robert (Server Storage)" wrote:

> Comments embedded...
>
> > 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
> TARGET FAILURE;
> 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 4.3.4.6) 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 5.4.3.1. (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
> work.
>
> 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().
>
> [Since:
> 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 hp.com
> Industry Standard Server Storage Advanced Technology
> Hewlett-Packard
>

*
* 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