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