Lines Matching refs:to
4 Modern filesystems feature checksumming of data and metadata to
8 application tried to write is most likely lost.
10 The solution is to ensure that the disk is actually storing what the
11 application meant it to. Recent additions to both the SCSI family
13 as SATA/T13 (External Path Protection) try to remedy this by adding
14 support for appending integrity metadata to an I/O. The integrity
18 for some protection schemes also that the I/O is written to the right
36 allow the operating system to interact with the integrity metadata
37 (IMD). We have been working with several FC/SAS HBA vendors to enable
38 the protection information to be transferred to and from their
42 information to each sector. The data + integrity metadata is stored
47 Because it is highly inconvenient for operating systems to deal with
49 encouraged them to allow separation of the data and integrity metadata
53 read. This means that Linux can DMA the data buffers to and from
54 host memory without changes to the page cache.
57 is somewhat heavy to compute in software. Benchmarks found that
60 lighter-weight checksum to be used when interfacing with the operating
62 The IP checksum received from the OS is converted to the 16-bit CRC
63 when writing and vice versa. This allows the integrity metadata to be
64 generated by Linux or the application at very low cost (comparable to
70 match up for an I/O to complete.
73 the choice in checksums is referred to as the Data Integrity
75 bodies (T10, T13), Oracle and its partners are trying to standardize
82 to be pinned to I/Os and sent to/received from controllers that
85 The advantage to the integrity extensions in SCSI and SATA is that
86 they enable us to protect the entire path from application to storage
91 Generally Linux/POSIX applications are agnostic to the intricacies of
94 transport protocols completely transparent to the application.
97 protection information to send to a disk. Consequently, the very
98 concept of an end-to-end protection scheme is a layering violation.
99 It is completely unreasonable for an application to be aware whether
102 The data integrity support implemented in Linux attempts to hide this
103 from the application. As far as the application (and to some extent
105 that's attached to the I/O.
107 The current implementation allows the block layer to automatically
109 intent is to move the integrity metadata calculation to userspace for
113 Some storage devices allow each hardware sector to be tagged with a
116 this extra space to tag sectors as they see fit. Because the tag
119 attached to a typical 4KB filesystem block.
122 access to manipulate the tags from user space. A passthrough
131 The data integrity patches add a new field to struct bio when
133 pointer to a struct bip which contains the bio integrity payload.
140 bip to the bio.
150 Because the format of the protection data is tied to the physical
157 The profile also contains a few constants to aid in completing,
160 Layered block devices will need to pick a profile that's appropriate
163 will require extra work due to the application tag.
175 to be verified upon completion.
197 To generate IMD for WRITE and to set up buffers for READ, the
200 Prior to calling this function, the bio data direction and start
202 added. It is up to the caller to ensure that the bio does not
219 nr_pages indicate how many pages of protection data need to be
220 stored in the integrity bio_vec list (similar to bio_alloc()).
227 Attaches a page containing integrity metadata to an existing
242 It is up to the receiver to process them and verify data
275 'tuple_size' must be set to match the size of the integrity
278 'tag_size' must be set to identify how many bytes of tag space