data protection format types

Gerry.Houlder at Gerry.Houlder at
Fri Aug 11 08:54:30 PDT 2006

* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
Well, it looks like you read the Type 3 protection description more
carefully than I did. Your reading is correct. The latest SBC-3 draft does
state that Type 3 protection uses the 2 byte Guard field as CRC protection
and only the other 6 bytes morph into a vendor specific protection
algorithm. I must have remembered (or misremembered?) something from an
earlier revision of the proposal that added Type 3 protection and didn't
notice the change in the final revision. Thanks for catching the
misstatement to prevent someone else from being confused.
	     Bob.Nixon at Emulex.						   
	     No Phone Info						To 
	     Available		       <Gerry.Houlder at>,	   
				       <t10 at>			   
	     08/10/2006 05:25						   
	     PM 						   Subject 
				       RE: data protection format types    
Hi, Gerry, thanks for the help with this!  I generally agree with your
discussion, but I have a problem with the last two sentences...I don't find
any indication that type 3 changes the behavior of the LOGICAL BLOCK GUARD
field.	SBC-3 makes that field subject to the standard, 4.16.3
refers its content to the single algorithm in 4.16.4, and nowhere in the
standard is anything that discusses any other way of computing the CRC.
This would lead me to believe that type 3 protection has exactly the same
CRC requirements as types 1 and 2, with the obvious exception of requiring
the other six bytes all to be FFh to turn off checking of data from the
What am I missing?
   - bob
-----Original Message-----
From: owner-t10 at [mailto:owner-t10 at]On Behalf Of
Gerry.Houlder at
Sent: Thursday, August 10, 2006 2:46 PM
To: t10 at
Subject: Re: data protection format types
* From the T10 Reflector (t10 at, posted by:
* Gerry.Houlder at
These three bits, as well as the other bits in the extended Inquiry VPD
page, are set by the target device depending on its capability. In the case
of these three bits, the target indicates whether it is capable of checking
the Guard field, the Application Tag field, and the Reference Tag field
(respectively) when the target is configured to use protection information.
The settings have a bearing on the values in the WRPROTECT, RDPROTECT, and
VPROTECT fields that the drive will accept.
 For example: if GRD_CHK=1, APP_CHK=0, and REF_CHK=1; if the RDPROTECT
field is set to 001b in a read command then the Guard field and Reference
Tag field will be checked but the Application Tag field will not. If the
target had reported APP_CHK=1 instead of zero, then the target is promising
to check the application tag field as well when the RDPROTECT field is set
to 001b. See the RDPROTECT field table in SBC-3 for an exhaustive list of
the cases.
These three bits are not really tied to the format type. They apply equally
well to types 1 and 2. Type 3 describes the use of the 8 bytes of
protection information as being vendor specific, so the three fields are no
longer defined. This kind of makes the GRD_CHECK, et. al. bits meaningless
for type 3.
	     Gary.Franco at emule
	     Sent by:							To
	     owner-t10 at	       <t10 at>
	     No Phone Info						cc
	     Available		       <Bob.Nixon at>
				       data protection format types
	     08/10/2006 02:46
I have a question with regard to the discussion in SPC4r04
In clause 7.6.4 Extended INQUIRY Data VPD page, there are 3 bits discussed
      APP_CHK and
They are defined as far as their meaning, but never discussed how they are
Is this part of the format process, or simply the capability of the device
firmware or design?
I got a response that said go look at any protected command (i.e.
read/write, etc.), however that does not answer the question.
Are these 3 bits somehow tied to the format type (type 1, 2, or 3)
Gary Franco Consultant Engineer
Emulex Network Systems
972-671-7433 Dallas Office
972-671-7435 Dallas Office Fax
720-652-6387 Longmont Colorado Office
720-494-1817 Longmont Colorado Office Fax
972-839-5694 Cell Phone
Today's Quote
It is not the cards you are dealt but what you do with them that counts.
This message contains confidential information of Emulex Corporation
intended only for listed recipients and should not be forwarded to anyone
If you have received this message in error, please delete it immediately.
Thank you.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list