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

Ralph Weber ralphoweber at
Tue Oct 22 14:04:27 PDT 2002

* From the T10 Reflector (t10 at, posted by:
* Ralph Weber <ralphoweber at>
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.

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

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

   N.B. With the pending introduction of EMDP (Enable Modify
   Data Pointers) support in SAS, the issue described by this
   SAM-3 statement takes full effect in SAS with the result
   that the validity of the claims cited in 2) above become
   dubious at best and very very hard to implement at worst.

02-404v0 contains several very bad ideas and while it sports
my name it does not have my support.

All the best.


* 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