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

Ralph Weber ralphoweber at compuserve.com
Thu Oct 31 17:24:43 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
It is beginning to look like a case can be made for SENSE LENGTH.
DATA-IN LENGTH continues to look iffy.

Regards.

.Ralph

"Elliott, Robert (Server Storage)" wrote:

> > * 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.
>
> They all do so to date.
>
> >                                    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.
>
> There's no allocation length communicated to the target
> in autosense.
>
> For REQUEST SENSE, there is this rule:
> "If the allocation length is eighteen or greater, and a device
> server returns less than eighteen bytes of data, the application
> client should assume that the bytes not transferred would have
> been zeros had the evice server returned those bytes."
>
> > 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.
>
> A residual is not provided in SAS response IUs for the same
> reason as parallel SCSI - the initiator is lockstepped with
> the target and its count of data received should match the
> target's count of data transmitted.  We're not worried about
> losing entire data frames in a vast store-and-forward fabric.
>
> --
> 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