Users Guide

Table Of Contents
Broadcom DRVVM-LPe-UG124-100
41
Emulex Drivers for VMware ESXi User Guide
Appendix B: lpfc Driver BlockGuard Functionality
This appendix describes how to enable BlockGuard and set lpfc driver module parameters.
B.1 Overview
The BlockGuard feature checks the integrity of data read from and written to the host to the disk and back through the SAN.
This check is implemented through the DIF defined in the ANSI T10 standard.
The Emulex lpfc driver supports T10 DIF Type 1. In the Type 1 implementation, the 8-byte DIF consists of a Ref Tag or LBA,
an App Tag, and a Guard Tag (or CRC). A Type 1 DIF is defined as having a 2-byte Guard Tag, a 2-byte App tag, and a
4-byte Ref tag, which consist of the lower 32 bits of the LBA.
The following figure shows a data block (with a 512-byte sector) with the 8-byte footer attached to the end. The contents of
the 8-byte footer are shown with the fields that make up the Type 1 DIF; the Guard Tag, the App Tag, and the Ref Tag. The
App Tag is not used by the lpfc driver.
Figure 1: Data Block Showing Type 1 DIF
When data is written, the DIF is generated by the host, or by the adapter, based on the block data and the LBA. The DIF
field is added to the end of each data block, and the data is sent through the SAN to the storage target. The storage target
validates the CRC and Ref tag and, if correct, stores both the data block and DIF on the physical media. If the CRC does
not match the data, the data was corrupted during the write. A Check Condition is returned back to the host with the
appropriate error code. The host records the error and retransmits the data to the target. In this way, data corruption is
detected immediately on a write and never committed to the physical media. On a read, the DIF is returned along with the
data block to the host, which validates the CRC and Ref tags. Because this validation is done by the hardware, it adds a very
small amount of latency to the I/O.
The format of the Guard Tag can optionally be an IP Checksum instead of the CRC mandated by T10 DIF. This can be
beneficial because the initiator host uses less CPU overhead to generate an IP Checksum than it does with a CRC. The IP
Checksum is typically passed as the Guard Tag between the initiator host and the adapter. The adapter hardware will
translate the IP Checksum into a CRC, or vice versa, on data being sent to or received from on the wire. The CRC is called
a DIF protection type, and the IP Checksum is referred to as DIX protection type.