SPIN/SPOUT reason for INC_512 bit

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Tue Aug 19 11:27:00 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
The background on this is that ATA/ SATA like to express their transfer
length in blocks of 512 bytes each, while SCSI prefers expressing the
transfer length in bytes for parameter data 9as opposed to user data
blocks). Adding the bit makes for easier translation between the SCSI
Security Protocol In /Out commands and the ATA Trusted Send/ Receive
commands (and vice versa). It also allows for a host application to have a
"compatibility mode" where it generates the data based on a number of 512
byte blocks without caring whether it will go to a SCSI or an ATA device.
The proper command can be formed by a device driver, depending on whether
the data stream is sent to an ATA or SCSI device.
A pure SCSI application can use the byte transfer length option and save
having to pad out the data to a 512 byte boundary.
	     "Mike Berhan"						   
	     <mikeb at bustrace.c						   
	     om>							To 
	     Sent by:		       "'T10 Reflector'" <t10 at t10.org>	   
	     owner-t10 at t10.org						cc 
	     No Phone Info						   
	     Available						   Subject 
				       SPIN/SPOUT reason for INC_512 bit   
	     08/19/2008 11:51						   
	     AM 							   
* 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