Page 3 of 3   « previous page

Data Integrity Extensions

• Allow transfer of data integrity information to and from the host operating system
• Allow separation of data and integrity metadata buffers
• Allow a lightweight checksum algorithm to limit impact on operating system performance

I/O Controller Data Integrity Extensions
While the increased resilience against errors between controller and storage device is an improvement, the design goal was to enable true end-to-end data integrity protection. An obvious approach was to expose the DIF information above the I/O controller level and let the operating system gain access to the integrity metadata.

Buffer Separation
There were a few problems with exposing the 520-byte sectors to the OS, however. Internally, operating systems generally work with sizes that are multiples of 512. On x86 and x86_64 hardware, the system page size is 4096 KB. This means that 8 sectors fit nicely in a page. It’s extremely inconvenient for the operating system to deal with buffers that are multiples of 520 bytes.

The Data Integrity Extensions allow the operating system to gain access to the DIF content without changing its internal buffer size. This is achieved by separating the data buffers and the integrity metadata buffers. The controller firmware will interleave the data and integrity buffers on write and split them on read.

Separating the data from the integrity metadata in the operating system also reduces the risk of data corruption. Now two buffers in different locations need to match up for an I/O request to be successfully completed.

Performance Implications
The DIF protection between I/O controller and disk is handled by custom hardware at near zero performance penalty. For true end-to-end data integrity, however, the application or the operating system needs to generate the protection information. Calculating the checksum in software obviously comes at a performance penalty and the T10 DIF standard mandates a heavyweight 16-bit CRC algorithm for the guard tag.

This CRC is quite expensive to calculate compared to other commonly used checksums. To alleviate the impact on system performance the TCP/IP checksum algorithm is used instead. This results in an almost negligible impact on system performance. The Data Integrity Extensions allow this alternate checksum type to be used by the operating system. The I/O controller will convert the IP checksum to the T10 DIF CRC when sending a request to the storage device and vice versa.

The net result is that a full end-to-end protection envelope can be provided at a very low cost in terms of processing overhead.

Linux Data Integrity Framework
Oracle has implemented support for DIF and the I/O Controller Data Integrity Extensions in the Linux kernel. The changes are released under the GNU General Public License and have been submitted for inclusion in the official kernel tree. With this, Linux becomes the first operating system to gain true end-to-end data integrity protection.

• Allows integrity metadata to be attached to an I/O request
• Allows filesystems to use the application tag for added recoverability
• Allows integrity metadata to be generated automatically for unmodified applications
• Will allow advanced applications to manually send and receive integrity metadata

The Linux changes allow integrity metadata to be generated and passed through the I/O stack. Currently the extensions are only accessible from within the kernel, but a userland API is in development. The goal is for all applications to be able to benefit from the extra data protection features.

At a recent Storage Networking industry conference, Oracle and its partners demonstrated an (unmodified) Oracle database running on Linux using the data integrity framework. The server used a prototype Emulex fibre channel controller, a disk tray from LSI, and disk drives from Seagate. We demonstrated how errors could be injected into the system, identified, isolated, and remedied without causing downtime or on-disk corruption.

The SCSI standard only governs communications between the I/O controller and storage device, and as such the interface between I/O controller and the operating system is outside the scope of the T10 organization. Consequently, Oracle and its partners have approached the Storage Networking Industry Association and set up Data Integrity Task Force with the intent to standardize the data integrity interfaces for applications, operating systems and I/O controllers.

Hardware products supporting DIF and the I/O Controller Data Integrity Extensions are scheduled for release in 2008.

Relevant Links

• Linux Data Integrity Framework: http://oss.oracle.com/projects/data-integrity/
• Whitepaper on Data Integrity: http://www.emulex.com/white/hba/DI.pdf

Page 3 of 3   « previous page