Propsal for handling DIFs with legacy operations

Walter Rassbach rassbach at nilenet.com
Mon Aug 11 16:08:02 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Walter Rassbach <rassbach at nilenet.com>
*
This note outlines a proposed method for handling the Data Integrity
Field (DIF) during legacy operations (i.e., operations that do not
explicitly handle the DIF). It is the result of an action item of mine
|from the phone conference on 8/8.

The proposed methods use a "mark value" in the guard sub-field and
specific values in the meta-data field to indicate the specific reason
that the block was "marked". Note that there be many reasons, outside
the scope of the proposed Data Integrity proposals, why a block may be
"marked", e.g., in RAID controller applications there is occasionally
the need to explicitly indicate that a block is to be treated as being
erroneous. If the guard method is checksum-based (using 1's complement
arithmetic), there is a built-in "mark" value of 0 (zero), which cannot
occur as a valid (calculated) guard value. If the guard calculation
method is a CRC, there is no guard value that does not occur. In this
situation, the proposed method for marking a block is to calculatethe
normal guard value for the block and then modify the result of that
calculation by XORing in a value of 0xBADB (assuming a 16-bit guard).

There are three main kinds of operations where there is no explict DIF
information available, namely:
1) Write (and Write&Verify) operations which do not transfer a DIF
(generally called "legacy" operations).
2) Write Same operations which do not transfer a template DIF.
3) Format operations.

There are also some other operations where DIF information is unlikely
to be available, e.g., XOR operations. These operations are not
discussed herein but the proposal herein could easily be extended to
cover such cases.

For legacy Write (and Write&Verify) operations, it is proposed that the
DIF be constructed as follows:
a) The REF sub-field is the lower 4 bytes of the LBA
b) The guard sub-field is the "mark" value, i.e., 0 (zero) using the
checksum-based calculation method or an explicit mark value using a
CRC-based guard calculation method.
c) A value of 0xFFF0 in the META sub-field

For a Write Same operation that does not provide a template DIF, a DIF
is constructed for each bloack as follows:
a) The REF sub-field is the lower 4 bytes of the LBA of the block --
Note that this changes for each block.
b) The guard sub-field is the "mark" value.
c) The META sub-field is set to 0xFFF5

For a Format operation, a DIF is constructed for each block as follows:
a) The REF sub-field is (again) the low 4 bytes of the LBA of the block
(changes per block).
b) The guard sub-field is the "mark" value.
c) The META sub-field is set to 0xFFFF.

The general pattern should be clear, i.e., set the guard sub-field to
the "mark" value and indicate the special circumstances in the META
field. The actual value of the REF field is not critical, but it seems
reasonable to set it to the lower 4 bytes of the LBA to provide some
form of block identification.

In addition to the above cases, the following are suggestted:
A) Reserve a META value of 0xFFFE (with a guard "mark") to indicate a
block that is explicitly marked as "bad".
B) Allow a device to, optionally, use META values of 0xFFC0 thriugh
0xFFEF to indicate blocks that were written using legacy Write
operations. The intention is that the device would select the specific
value according to the initiator that issued the legacy Write. This
provides a mechanism for a simple audit trail to determine which
initiators are (still) using legacy Write operations. The association
between the value used and the initiator (or, possibly a group of
initiators) is outside the scope of this proposal -- Such usages would
be vendor specific.
C) Reserve META values of 0xFF80 through 0xFFBF for future expansion and
values of 0xFF00 through 0xFF7F for vendor unique usages.

This would leave META values of 0x0000 through 0xFEFF (when combined
with a "marked" guard) available for application usage. Note that the
META values are unrestricted when used with a guard value other than the
"mark" value, but it probably would be a good idea to avoid META values
of 0xFFxx.

*
* 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