Documentation/block/data-integrity.rst

Source file repositories/reference/linux-study-clean/Documentation/block/data-integrity.rst

File Facts

System
Linux kernel
Corpus path
Documentation/block/data-integrity.rst
Extension
.rst
Size
10332 bytes
Lines
249
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==============
Data Integrity
==============

1. Introduction
===============

Modern filesystems feature checksumming of data and metadata to
protect against data corruption.  However, the detection of the
corruption is done at read time which could potentially be months
after the data was written.  At that point the original data that the
application tried to write is most likely lost.

The solution is to ensure that the disk is actually storing what the
application meant it to.  Recent additions to both the SCSI family
protocols (SBC Data Integrity Field, SCC protection proposal) as well
as SATA/T13 (External Path Protection) try to remedy this by adding
support for appending integrity metadata to an I/O.  The integrity
metadata (or protection information in SCSI terminology) includes a
checksum for each sector as well as an incrementing counter that
ensures the individual sectors are written in the right order.  And
for some protection schemes also that the I/O is written to the right
place on disk.

Current storage controllers and devices implement various protective
measures, for instance checksumming and scrubbing.  But these
technologies are working in their own isolated domains or at best
between adjacent nodes in the I/O path.  The interesting thing about
DIF and the other integrity extensions is that the protection format
is well defined and every node in the I/O path can verify the
integrity of the I/O and reject it if corruption is detected.  This
allows not only corruption prevention but also isolation of the point
of failure.

2. The Data Integrity Extensions
================================

As written, the protocol extensions only protect the path between
controller and storage device.  However, many controllers actually
allow the operating system to interact with the integrity metadata
(IMD).  We have been working with several FC/SAS HBA vendors to enable
the protection information to be transferred to and from their
controllers.

The SCSI Data Integrity Field works by appending 8 bytes of protection
information to each sector.  The data + integrity metadata is stored
in 520 byte sectors on disk.  Data + IMD are interleaved when
transferred between the controller and target.  The T13 proposal is
similar.

Because it is highly inconvenient for operating systems to deal with
520 (and 4104) byte sectors, we approached several HBA vendors and
encouraged them to allow separation of the data and integrity metadata
scatter-gather lists.

The controller will interleave the buffers on write and split them on
read.  This means that Linux can DMA the data buffers to and from
host memory without changes to the page cache.

Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs
is somewhat heavy to compute in software.  Benchmarks found that
calculating this checksum had a significant impact on system
performance for a number of workloads.  Some controllers allow a
lighter-weight checksum to be used when interfacing with the operating
system.  Emulex, for instance, supports the TCP/IP checksum instead.
The IP checksum received from the OS is converted to the 16-bit CRC
when writing and vice versa.  This allows the integrity metadata to be
generated by Linux or the application at very low cost (comparable to
software RAID5).

Annotation

Implementation Notes