SBC-2 "check only the block guard" protection option

Fri Mar 19 08:27:41 PST 2004

* From the T10 Reflector (t10 at t10.org), posted by:
* "Holt, Keith" <keith.holt at lsil.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C40DCF.19CCEECE
Content-Type: text/plain;
	charset="ISO-8859-1"

Re:  Need for additional SBC-2 data protection option to check only the
logical block guard 

The RDPROTECT and WRPROTECT data protection fields were introduced in
Revision 2 of the Simplified End-to-End Data Protection Proposal
(03-176r2, July 31, 2003).  The field sizes were two bits each, which
allowed for four different protection options.   In the August 2003 Data
Integrity Study Group meeting (see 03-281r0 for the meeting minutes),
there was consensus that three of the options had to be as follows:

1) "no protection information included" 
2) "protection information included, check all protection fields" 
   (the refinement for APPLICATION TAG ownership came later) 
3) "protection information included, don't check any of the protection
fields" 

The pros and cons of various usages for the fourth option were
discussed.  In the end, the group recommended that the fourth option be
defined as "check the REFERENCE TAG, but don't check BLOCK GUARD" in
order to satisfy the usage model that called for the guard to be a
checksum, rather than CRC.  This left out the option of "check the BLOCK
GUARD, but don't check any other fields."  The thought was that this
case could always be covered by the "don't check anything" option.  Two
recent developments have led me to believe that we need to reconsider
this decision.

The first is that in the November CAP meeting, it was suggested that the
field sizes be changed to 3 bits each for future expansion.  This change
was made in the final draft of the proposal, 03-365r1.  No additional
protection options were added.  With the RDPROTECT and WRPROTECT field
sizes in SBC-2 at 3 bits each, only 4 of the 8 possible combinations are
defined, so the infrastructure is already in place to easily add an
additional option.

The second development is that there has been considerable discussion in
the last few CAP meetings regarding REFERENCE TAG usage models,
especially in the context of layered virtualization devices between the
host and media.  SBC-2 Revision 12 requires that the REFERENCE TAG be
equal to the lower 4 bytes of the LBA.  There is a proposal being
developed to allow the REFERENCE TAG to differ from the LBA, 03-307r6,
32 Byte Commands for End-to-End Data Protection.

Given the possibility that we may ultimately have some devices that
support the "non LBA locked" model and some that don't, I think it would
be prudent to provide a means for the application client to instruct the
device server to treat the REFERENCE TAG as opaque data.  The only
option available to accomplish this is the "don't check any of the
protection fields" option.  This means that the device server would not
be able to check the BLOCK GUARD, either.  It's my intent to submit a
proposal to define an additional option to specify that the device
server should check only the BLOCK GUARD.  I'm interested in knowing
whether or not others believe this option is needed, as well.

Keith 
-- 
Keith Holt 
LSI Logic Storage Systems Inc. 
keith.holt at lsil.com 
316-636-8665 

------_=_NextPart_001_01C40DCF.19CCEECE
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

 SBC-2 ;check only the block guard; protection = option Re:  Need for additional SBC-2 data protection = option to check only the logical block guard The RDPROTECT and WRPROTECT data protection fields = were introduced in Revision 2 of the Simplified End-to-End Data = Protection Proposal (03-176r2, July 31, 2003).  The field sizes = were two bits each, which allowed for four different protection = options.   In the August 2003 Data Integrity Study Group = meeting (see 03-281r0 for the meeting minutes), there was consensus = that three of the options had to be as follows: 1) ;no protection information = included; 
2) ;protection information included, check all = protection fields; 
   (the refinement for APPLICATION TAG = ownership came later) 
3) ;protection information included, don't = check any of the protection fields; The pros and cons of various usages for the fourth = option were discussed.  In the end, the group recommended that the = fourth option be defined as ;check the REFERENCE TAG, but don't = check BLOCK GUARD; in order to satisfy the usage model that called = for the guard to be a checksum, rather than CRC.  This left out = the option of ;check the BLOCK GUARD, but don't check any other = fields.;  The thought was that this case could always be = covered by the ;don't check anything; option.  Two = recent developments have led me to believe that we need to reconsider = this decision. The first is that in the November CAP meeting, it was = suggested that the field sizes be changed to 3 bits each for future = expansion.  This change was made in the final draft of the = proposal, 03-365r1.  No additional protection options were = added.  With the RDPROTECT and WRPROTECT field sizes in SBC-2 at 3 = bits each, only 4 of the 8 possible combinations are defined, so the = infrastructure is already in place to easily add an additional = option. The second development is that there has been = considerable discussion in the last few CAP meetings regarding = REFERENCE TAG usage models, especially in the context of layered = virtualization devices between the host and media.  SBC-2 Revision = 12 requires that the REFERENCE TAG be equal to the lower 4 bytes of the = LBA.  There is a proposal being developed to allow the REFERENCE = TAG to differ from the LBA, 03-307r6, 32 Byte Commands for End-to-End = Data Protection. Given the possibility that we may ultimately have = some devices that support the ;non LBA locked; model and some = that don't, I think it would be prudent to provide a means for the = application client to instruct the device server to treat the REFERENCE = TAG as opaque data.  The only option available to accomplish this = is the ;don't check any of the protection fields; = option.  This means that the device server would not be able to = check the BLOCK GUARD, either.  It's my intent to submit a = proposal to define an additional option to specify that the device = server should check only the BLOCK GUARD.  I'm interested in = knowing whether or not others believe this option is needed, as = well. Keith 
-- 
Keith Holt 
LSI Logic Storage Systems Inc. 
keith.holt at lsil.com 
316-636-8665 
------_=_NextPart_001_01C40DCF.19CCEECE--