Lines Matching +full:trim +full:- +full:data +full:- +full:valid
2 dm-integrity
5 The dm-integrity target emulates a block device that has additional
6 per-sector tags that can be used for storing integrity information.
9 writing the sector and the integrity tag must be atomic - i.e. in case of
12 To guarantee write atomicity, the dm-integrity target uses journal, it
13 writes sector data and integrity tags into a journal, commits the journal
14 and then copies the data and integrity tags to their respective location.
16 The dm-integrity target can be used with the dm-crypt target - in this
17 situation the dm-crypt target creates the integrity data and passes them
18 to the dm-integrity target via bio_integrity_payload attached to the bio.
19 In this mode, the dm-crypt and dm-integrity targets provide authenticated
20 disk encryption - if the attacker modifies the encrypted device, an I/O
21 error is returned instead of random data.
23 The dm-integrity target can also be used as a standalone target, in this
25 mode, the dm-integrity target can be used to detect silent data
28 There's an alternate mode of operation where dm-integrity uses a bitmap
30 region's data and integrity tags are not synchronized - if the machine
32 is faster than the journal mode, because we don't have to write the data
33 twice, but it is also less reliable, because if data corruption happens
38 zeroes. If the superblock is neither valid nor zeroed, the dm-integrity
41 Accesses to the on-disk metadata area containing checksums (aka tags) are
42 buffered using dm-bufio. When an access to any given metadata area
48 a full write to the data covered by a single buffer.
53 2. load the dm-integrity target with one-sector size, the kernel driver
55 3. unload the dm-integrity target
57 5. load the dm-integrity target with the target size
59 6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target
67 2. the number of reserved sector at the beginning of the device - the
68 dm-integrity won't read of write these sectors
70 3. the size of the integrity tag (if "-" is used, the size is taken from
71 the internal-hash algorithm)
75 D - direct writes (without journal)
77 not used and data sectors and integrity tags are written
78 separately. In case of crash, it is possible that the data
80 J - journaled writes
81 data and integrity tags are written to the
83 either both data and tag or none of them are written. The
85 data have to be written twice.
86 B - bitmap mode - data and metadata are written without any
88 regions where data and metadata don't match. This mode can
90 R - recovery mode - in this mode, journal is not replayed,
92 allowed. This mode is useful for data recovery if the
95 I - inline mode - in this mode, dm-integrity will store integrity
96 data directly in the underlying device sectors.
98 allows storing user integrity data and provides enough
116 Don't interleave the data and metadata on the device. Use a
135 When this argument is used, the dm-integrity target won't accept
140 will protect the data against accidental corruption.
143 cryptographic authentication of the data without encryption.
146 from an upper layer target, such as dm-crypt. The upper layer
150 Recalculate the integrity tags automatically. It is only valid
171 This option is not needed when using internal-hash because in this
177 The size of a data block in bytes. The larger the block size the
178 less overhead there is for per-block integrity metadata.
183 512-byte sectors that corresponds to one bitmap bit.
190 Allow block discard requests (a.k.a. TRIM) for the integrity device.
195 space-efficient. If this option is not present, large padding is
196 used - that is for compatibility with older kernels.
201 - the section number is mixed to the mac, so that an attacker can't
203 - the superblock is protected by journal_mac
204 - a 16-byte salt stored in the superblock is mixed to the mac, so
211 default for security reasons - an attacker could modify the volume,
219 data depend on them and the reloaded target would be non-functional.
223 bytes, it will take 128 KiB of tags to track a full data area, requiring
224 256 sectors of metadata per data area. With the default buffer_sectors of
226 per 16 MiB of data.
231 2. provided data sectors - that is the number of sectors that the user
233 3. the current recalculating position (or '-' if we didn't recalculate)
244 * magic string - identifies that the device was formatted
249 * provided data sectors - the number of sectors that this target
252 bios that access data beyond the "provided data sectors" limit.
255 - a flag is set if journal_mac is used
257 - recalculating is in progress
259 - journal area contains the bitmap of dirty
268 - every journal entry contains:
270 * logical sector (specifies where the data and tag should
272 * last 8 bytes of data
275 - every metadata sector ends with
277 * mac (8-bytes), all the macs in 8 metadata sectors form a
278 64-byte value. It is used to store hmac of sector
284 * data area (the size is variable; it depends on how many journal
287 - every sector in the data area contains:
289 * data (504 bytes of data, the last 8 bytes are stored in
294 512-byte sector of the journal ends with 8-byte commit id. If the
300 * one or more runs of interleaved tags and data.
303 * tag area - it contains integrity tags. There is one tag for each
304 sector in the data area. The size of this area is always 4KiB or
306 * data area - it contains data sectors. The number of data sectors