Data Integrity telecon, Aug 8

Jim.Coomes at Jim.Coomes at
Mon Aug 11 12:14:07 PDT 2003

* From the T10 Reflector (t10 at, posted by:
* Jim.Coomes at
The following is a summary of EDC (End to End Data Checking)
conference call Aug 8, 03.

The option of a checksum to a CRC guard algorithm was discussed.
A position was taken that there is an advantage for the data
drives of a RAID to use a checksum for checking stripe
consistency. Walter Rassbach will post a document supporting this

Another support for a checksum was it would be easier to
implement in software. Another opinion is a 16 bit CRC is as easy
to calculate as the checksum. Pat Thaler will post pseudo code
for the proposed 16 bit CRC to review.

The use of a 16 bit versus a 32 bit CRC was discussed. The main
support for a 32 bit CRC was to error on the side of robustness.
What errors is the guard protecting against? Implementors already
protect memories against bit errors. The CRC / guard is
protecting against higher level errors such as a memory page
access error. EDC proposals will be updated to include the 16 bit
CRC. With the 16 bit CRC, an 8 byte DIF can support a 4 byte ref
tag, 2 byte meta data, and 2 bytes of guard.

After a discussion of support for legacy initiators on EDC
formatted targets, it was decided they have to be supported. EDC
formatted targets are required to pad the DIF on legacy writes
and strip it on legacy reads.

The question of what DIF an EDC enabled target adds to user data
|from a legacy initiator was discussed. After resistance to
putting the default value in a mode page, proposals will be
accepted to define a unique (yellow flag) value for the DIF that
disables checking.

Walter will send out some ideas on the yellow DIF. One issue is
which fields (ref tag, meta data, guard) of the DIF are included
in the yellow value.

The function of passing the initial value of the ref tag in the
CDB was debated. New (long) CDBs are required to implement
passing the initial ref tag. If this function is not available,
the ref tag is locked to the LBA in the CDB. If there is
remapping of the LBA such as in a RAID controller on writes the
original DIF is not passed to the next target level. On reads,
the DIF has to be regenerated. There was an argument that this is
not end to end checking. No consensus was reached. Proposals with
and without this function are likely to be presented to CAP.

* 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