Lines Matching +full:data +full:- +full:size
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
43 occurs, each unique metadata area gets its own buffer(s). The buffer size
44 is capped at the size of the metadata area, but may be smaller, thereby
46 buffer size will produce a smaller resulting read/write operation to the
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
60 with the size "provided_data_sectors"
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
106 The size of journal, this argument is used only if formatting the
116 Don't interleave the data and metadata on the device. Use a
124 The journal watermark in percents. When the size of the journal
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
162 the size of files that were written. To protect against this
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.
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.
222 block_size of 512, and an internal_hash of crc32c with a tag size of 4
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)
240 storing LUKS metadata or for other purpose), the size of the reserved
244 * magic string - identifies that the device was formatted
247 * integrity tag size
249 * provided data sectors - the number of sectors that this target
250 provides (i.e. the size of the device minus the size of all
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
273 * integrity tag (the size is specified in the superblock)
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