SPIN/SPOUT reason for INC_512 bit

Ralph Weber roweber at ieee.org
Tue Aug 19 11:53:02 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
If memory serves, the INC_512 bit was defined to aid compatibility
between the SCSI SECURITY PROTOCOL IN/OUT commands and the ATA
TRUSTED IN/OUT commands (where everything behaves as if the INC_512
bit is set to one.
All the best,
.Ralph
Mike Berhan wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mike Berhan" <mikeb at bustrace.com>
> *
> I cannot find the history behind the INC_512 bit in the SPIN/SPOUT CDBs.
> The definition of this bit in SPC-4 is:
>
> "A 512 increment (INC_512) bit set to one specifies that the ALLOCATION
> LENGTH field (see 4.3.5.6) expresses the maximum number of bytes available
> to receive data in increments of 512 bytes (e.g., a value of one means 512
> bytes, two means 1 024 bytes, etc.). Pad bytes may or may not be appended
to
> meet this length. Pad bytes shall have a value of 00h. An INC_512 bit set
to
> zero specifies that the ALLOCATION LENGTH field expresses the number of
> bytes to be transferred."
>
> Since the ALLOCATION LENGTH field is 4 bytes in length, I'm not sure why
> there was a need to define the INC_512 bit?  I see a variety of
> specifications state that INC_512 of 1 shall always return an Invalid Field
> in CDB check condition.  I also see that for those devices that use INC_512
> (e.g. some IEEE-1667 devices), it doesn't really seem to be necessary to me
> since the ALLOCATION LENGTH is large enough to describe the transfer. 
There
> must be some benefit that I'm missing.  Thank you for the clarification.
>
> Mike
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>
>   
*
* 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