SPIN/SPOUT reason for INC_512 bit

James.C.Hatfield at seagate.com James.C.Hatfield at seagate.com
Tue Aug 19 11:55:26 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
You mention
   "I see a variety of specifications state that INC_512
   of 1 shall always return an Invalid Field in CDB check condition."
SPC-4 does not state this at all. Please indicate what specifications you
are refering to.
-----------------------------------------------------
The reason that INC_512 was created was for two reasons:
1)    for compatability and easier translation with the ATA equivalent
commands
      which ONLY transfer in multiples of 512-byte chunks; and
2)    some T10 members demanded that byte-sized transfers be allowed
      so that they didn't have to suffer bus (especially) overhead to
      transfer padding bytes.
So, INC_512 was a compromise that allowed both camps of potential users
to get what they want.
-----------------------------------------------------
For SCSI, the 32-bit size of the ALLOCATION LENGTH field
- the max transfer size (INC_512=0)	  = 4,294,967,295 bytes
- the max transfer size (INC_512=1)	  = 4,294,967,295 chunks of
512-bytes
			      =  7,0368,744,161,280 bytes
But for ATA, the max transfer size field is only 16 bits
- the max transfer size (INC_512=1)	  = 65,535 chunks of 512-bytes
			      =  1,073,725,440 bytes
If you have a SECURITY PROTOCOL that intends to operated in both ATA and
SCSI,
the max transfer size comes from ATA limits.
-----------------------------------------------------
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2766
==========================================
	     "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 10: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