.. | .. |
---|
| 1 | +# SPDX-License-Identifier: GPL-2.0-only |
---|
1 | 2 | # |
---|
2 | 3 | # Block device driver configuration |
---|
3 | 4 | # |
---|
.. | .. |
---|
14 | 15 | |
---|
15 | 16 | config BLK_DEV_MD |
---|
16 | 17 | tristate "RAID support" |
---|
17 | | - ---help--- |
---|
| 18 | + help |
---|
18 | 19 | This driver lets you combine several hard disk partitions into one |
---|
19 | 20 | logical block device. This can be used to simply append one |
---|
20 | 21 | partition to another one or to combine several redundant hard disks |
---|
.. | .. |
---|
26 | 27 | |
---|
27 | 28 | More information about Software RAID on Linux is contained in the |
---|
28 | 29 | Software RAID mini-HOWTO, available from |
---|
29 | | - <http://www.tldp.org/docs.html#howto>. There you will also learn |
---|
| 30 | + <https://www.tldp.org/docs.html#howto>. There you will also learn |
---|
30 | 31 | where to get the supporting user space utilities raidtools. |
---|
31 | 32 | |
---|
32 | 33 | If unsure, say N. |
---|
.. | .. |
---|
35 | 36 | bool "Autodetect RAID arrays during kernel boot" |
---|
36 | 37 | depends on BLK_DEV_MD=y |
---|
37 | 38 | default y |
---|
38 | | - ---help--- |
---|
| 39 | + help |
---|
39 | 40 | If you say Y here, then the kernel will try to autodetect raid |
---|
40 | | - arrays as part of its boot process. |
---|
| 41 | + arrays as part of its boot process. |
---|
41 | 42 | |
---|
42 | | - If you don't use raid and say Y, this autodetection can cause |
---|
| 43 | + If you don't use raid and say Y, this autodetection can cause |
---|
43 | 44 | a several-second delay in the boot time due to various |
---|
44 | 45 | synchronisation steps that are part of this step. |
---|
45 | 46 | |
---|
.. | .. |
---|
48 | 49 | config MD_LINEAR |
---|
49 | 50 | tristate "Linear (append) mode" |
---|
50 | 51 | depends on BLK_DEV_MD |
---|
51 | | - ---help--- |
---|
| 52 | + help |
---|
52 | 53 | If you say Y here, then your multiple devices driver will be able to |
---|
53 | 54 | use the so-called linear mode, i.e. it will combine the hard disk |
---|
54 | 55 | partitions by simply appending one to the other. |
---|
.. | .. |
---|
61 | 62 | config MD_RAID0 |
---|
62 | 63 | tristate "RAID-0 (striping) mode" |
---|
63 | 64 | depends on BLK_DEV_MD |
---|
64 | | - ---help--- |
---|
| 65 | + help |
---|
65 | 66 | If you say Y here, then your multiple devices driver will be able to |
---|
66 | 67 | use the so-called raid0 mode, i.e. it will combine the hard disk |
---|
67 | 68 | partitions into one logical device in such a fashion as to fill them |
---|
.. | .. |
---|
70 | 71 | |
---|
71 | 72 | Information about Software RAID on Linux is contained in the |
---|
72 | 73 | Software-RAID mini-HOWTO, available from |
---|
73 | | - <http://www.tldp.org/docs.html#howto>. There you will also |
---|
| 74 | + <https://www.tldp.org/docs.html#howto>. There you will also |
---|
74 | 75 | learn where to get the supporting user space utilities raidtools. |
---|
75 | 76 | |
---|
76 | 77 | To compile this as a module, choose M here: the module |
---|
.. | .. |
---|
81 | 82 | config MD_RAID1 |
---|
82 | 83 | tristate "RAID-1 (mirroring) mode" |
---|
83 | 84 | depends on BLK_DEV_MD |
---|
84 | | - ---help--- |
---|
| 85 | + help |
---|
85 | 86 | A RAID-1 set consists of several disk drives which are exact copies |
---|
86 | 87 | of each other. In the event of a mirror failure, the RAID driver |
---|
87 | 88 | will continue to use the operational mirrors in the set, providing |
---|
.. | .. |
---|
92 | 93 | |
---|
93 | 94 | Information about Software RAID on Linux is contained in the |
---|
94 | 95 | Software-RAID mini-HOWTO, available from |
---|
95 | | - <http://www.tldp.org/docs.html#howto>. There you will also |
---|
| 96 | + <https://www.tldp.org/docs.html#howto>. There you will also |
---|
96 | 97 | learn where to get the supporting user space utilities raidtools. |
---|
97 | 98 | |
---|
98 | 99 | If you want to use such a RAID-1 set, say Y. To compile this code |
---|
.. | .. |
---|
103 | 104 | config MD_RAID10 |
---|
104 | 105 | tristate "RAID-10 (mirrored striping) mode" |
---|
105 | 106 | depends on BLK_DEV_MD |
---|
106 | | - ---help--- |
---|
| 107 | + help |
---|
107 | 108 | RAID-10 provides a combination of striping (RAID-0) and |
---|
108 | 109 | mirroring (RAID-1) with easier configuration and more flexible |
---|
109 | 110 | layout. |
---|
.. | .. |
---|
128 | 129 | select ASYNC_XOR |
---|
129 | 130 | select ASYNC_PQ |
---|
130 | 131 | select ASYNC_RAID6_RECOV |
---|
131 | | - ---help--- |
---|
| 132 | + help |
---|
132 | 133 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
---|
133 | 134 | the capacity of C * (N - 1) MB, and protects against a failure |
---|
134 | 135 | of a single drive. For a given sector (row) number, (N - 1) drives |
---|
.. | .. |
---|
147 | 148 | |
---|
148 | 149 | Information about Software RAID on Linux is contained in the |
---|
149 | 150 | Software-RAID mini-HOWTO, available from |
---|
150 | | - <http://www.tldp.org/docs.html#howto>. There you will also |
---|
| 151 | + <https://www.tldp.org/docs.html#howto>. There you will also |
---|
151 | 152 | learn where to get the supporting user space utilities raidtools. |
---|
152 | 153 | |
---|
153 | 154 | If you want to use such a RAID-4/RAID-5/RAID-6 set, say Y. To |
---|
.. | .. |
---|
182 | 183 | depends on BLK_DEV_MD |
---|
183 | 184 | depends on DLM |
---|
184 | 185 | default n |
---|
185 | | - ---help--- |
---|
| 186 | + help |
---|
186 | 187 | Clustering support for MD devices. This enables locking and |
---|
187 | 188 | synchronization across multiple systems on the cluster, so all |
---|
188 | 189 | nodes in the cluster can access the MD devices simultaneously. |
---|
.. | .. |
---|
202 | 203 | tristate "Device mapper support" |
---|
203 | 204 | select BLK_DEV_DM_BUILTIN |
---|
204 | 205 | depends on DAX || DAX=n |
---|
205 | | - ---help--- |
---|
| 206 | + help |
---|
206 | 207 | Device-mapper is a low level volume manager. It works by allowing |
---|
207 | 208 | people to specify mappings for ranges of logical sectors. Various |
---|
208 | 209 | mapping types are available, in addition people may write their own |
---|
.. | .. |
---|
215 | 216 | |
---|
216 | 217 | If unsure, say N. |
---|
217 | 218 | |
---|
218 | | -config DM_MQ_DEFAULT |
---|
219 | | - bool "request-based DM: use blk-mq I/O path by default" |
---|
220 | | - depends on BLK_DEV_DM |
---|
221 | | - ---help--- |
---|
222 | | - This option enables the blk-mq based I/O path for request-based |
---|
223 | | - DM devices by default. With the option the dm_mod.use_blk_mq |
---|
224 | | - module/boot option defaults to Y, without it to N, but it can |
---|
225 | | - still be overriden either way. |
---|
226 | | - |
---|
227 | | - If unsure say N. |
---|
228 | | - |
---|
229 | 219 | config DM_DEBUG |
---|
230 | 220 | bool "Device mapper debugging support" |
---|
231 | 221 | depends on BLK_DEV_DM |
---|
232 | | - ---help--- |
---|
| 222 | + help |
---|
233 | 223 | Enable this for messages that may help debug device-mapper problems. |
---|
234 | 224 | |
---|
235 | 225 | If unsure, say N. |
---|
.. | .. |
---|
237 | 227 | config DM_BUFIO |
---|
238 | 228 | tristate |
---|
239 | 229 | depends on BLK_DEV_DM |
---|
240 | | - ---help--- |
---|
| 230 | + help |
---|
241 | 231 | This interface allows you to do buffered I/O on a device and acts |
---|
242 | 232 | as a cache, holding recently-read blocks in memory and performing |
---|
243 | 233 | delayed writes. |
---|
.. | .. |
---|
245 | 235 | config DM_DEBUG_BLOCK_MANAGER_LOCKING |
---|
246 | 236 | bool "Block manager locking" |
---|
247 | 237 | depends on DM_BUFIO |
---|
248 | | - ---help--- |
---|
| 238 | + help |
---|
249 | 239 | Block manager locking can catch various metadata corruption issues. |
---|
250 | 240 | |
---|
251 | 241 | If unsure, say N. |
---|
.. | .. |
---|
254 | 244 | bool "Keep stack trace of persistent data block lock holders" |
---|
255 | 245 | depends on STACKTRACE_SUPPORT && DM_DEBUG_BLOCK_MANAGER_LOCKING |
---|
256 | 246 | select STACKTRACE |
---|
257 | | - ---help--- |
---|
| 247 | + help |
---|
258 | 248 | Enable this for messages that may help debug problems with the |
---|
259 | 249 | block manager locking used by thin provisioning and caching. |
---|
260 | 250 | |
---|
.. | .. |
---|
263 | 253 | config DM_BIO_PRISON |
---|
264 | 254 | tristate |
---|
265 | 255 | depends on BLK_DEV_DM |
---|
266 | | - ---help--- |
---|
| 256 | + help |
---|
267 | 257 | Some bio locking schemes used by other device-mapper targets |
---|
268 | 258 | including thin provisioning. |
---|
269 | 259 | |
---|
.. | .. |
---|
272 | 262 | config DM_UNSTRIPED |
---|
273 | 263 | tristate "Unstriped target" |
---|
274 | 264 | depends on BLK_DEV_DM |
---|
275 | | - ---help--- |
---|
| 265 | + help |
---|
276 | 266 | Unstripes I/O so it is issued solely on a single drive in a HW |
---|
277 | 267 | RAID0 or dm-striped target. |
---|
278 | 268 | |
---|
279 | 269 | config DM_CRYPT |
---|
280 | 270 | tristate "Crypt target support" |
---|
281 | 271 | depends on BLK_DEV_DM |
---|
| 272 | + depends on (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n) |
---|
282 | 273 | select CRYPTO |
---|
283 | 274 | select CRYPTO_CBC |
---|
284 | | - ---help--- |
---|
| 275 | + select CRYPTO_ESSIV |
---|
| 276 | + help |
---|
285 | 277 | This device-mapper target allows you to create a device that |
---|
286 | 278 | transparently encrypts the data on it. You'll need to activate |
---|
287 | 279 | the ciphers you're going to use in the cryptoapi configuration. |
---|
.. | .. |
---|
319 | 311 | tristate "Snapshot target" |
---|
320 | 312 | depends on BLK_DEV_DM |
---|
321 | 313 | select DM_BUFIO |
---|
322 | | - ---help--- |
---|
323 | | - Allow volume managers to take writable snapshots of a device. |
---|
| 314 | + help |
---|
| 315 | + Allow volume managers to take writable snapshots of a device. |
---|
324 | 316 | |
---|
325 | 317 | config DM_THIN_PROVISIONING |
---|
326 | 318 | tristate "Thin provisioning target" |
---|
327 | 319 | depends on BLK_DEV_DM |
---|
328 | 320 | select DM_PERSISTENT_DATA |
---|
329 | 321 | select DM_BIO_PRISON |
---|
330 | | - ---help--- |
---|
331 | | - Provides thin provisioning and snapshots that share a data store. |
---|
| 322 | + help |
---|
| 323 | + Provides thin provisioning and snapshots that share a data store. |
---|
332 | 324 | |
---|
333 | 325 | config DM_CACHE |
---|
334 | 326 | tristate "Cache target (EXPERIMENTAL)" |
---|
.. | .. |
---|
336 | 328 | default n |
---|
337 | 329 | select DM_PERSISTENT_DATA |
---|
338 | 330 | select DM_BIO_PRISON |
---|
339 | | - ---help--- |
---|
340 | | - dm-cache attempts to improve performance of a block device by |
---|
341 | | - moving frequently used data to a smaller, higher performance |
---|
342 | | - device. Different 'policy' plugins can be used to change the |
---|
343 | | - algorithms used to select which blocks are promoted, demoted, |
---|
344 | | - cleaned etc. It supports writeback and writethrough modes. |
---|
| 331 | + help |
---|
| 332 | + dm-cache attempts to improve performance of a block device by |
---|
| 333 | + moving frequently used data to a smaller, higher performance |
---|
| 334 | + device. Different 'policy' plugins can be used to change the |
---|
| 335 | + algorithms used to select which blocks are promoted, demoted, |
---|
| 336 | + cleaned etc. It supports writeback and writethrough modes. |
---|
345 | 337 | |
---|
346 | 338 | config DM_CACHE_SMQ |
---|
347 | 339 | tristate "Stochastic MQ Cache Policy (EXPERIMENTAL)" |
---|
348 | 340 | depends on DM_CACHE |
---|
349 | 341 | default y |
---|
350 | | - ---help--- |
---|
351 | | - A cache policy that uses a multiqueue ordered by recent hits |
---|
352 | | - to select which blocks should be promoted and demoted. |
---|
353 | | - This is meant to be a general purpose policy. It prioritises |
---|
354 | | - reads over writes. This SMQ policy (vs MQ) offers the promise |
---|
355 | | - of less memory utilization, improved performance and increased |
---|
356 | | - adaptability in the face of changing workloads. |
---|
| 342 | + help |
---|
| 343 | + A cache policy that uses a multiqueue ordered by recent hits |
---|
| 344 | + to select which blocks should be promoted and demoted. |
---|
| 345 | + This is meant to be a general purpose policy. It prioritises |
---|
| 346 | + reads over writes. This SMQ policy (vs MQ) offers the promise |
---|
| 347 | + of less memory utilization, improved performance and increased |
---|
| 348 | + adaptability in the face of changing workloads. |
---|
357 | 349 | |
---|
358 | 350 | config DM_WRITECACHE |
---|
359 | 351 | tristate "Writecache target" |
---|
360 | 352 | depends on BLK_DEV_DM |
---|
361 | | - ---help--- |
---|
| 353 | + help |
---|
362 | 354 | The writecache target caches writes on persistent memory or SSD. |
---|
363 | 355 | It is intended for databases or other programs that need extremely |
---|
364 | 356 | low commit latency. |
---|
.. | .. |
---|
366 | 358 | The writecache target doesn't cache reads because reads are supposed |
---|
367 | 359 | to be cached in standard RAM. |
---|
368 | 360 | |
---|
| 361 | +config DM_EBS |
---|
| 362 | + tristate "Emulated block size target (EXPERIMENTAL)" |
---|
| 363 | + depends on BLK_DEV_DM |
---|
| 364 | + select DM_BUFIO |
---|
| 365 | + help |
---|
| 366 | + dm-ebs emulates smaller logical block size on backing devices |
---|
| 367 | + with larger ones (e.g. 512 byte sectors on 4K native disks). |
---|
| 368 | + |
---|
369 | 369 | config DM_ERA |
---|
370 | 370 | tristate "Era target (EXPERIMENTAL)" |
---|
371 | 371 | depends on BLK_DEV_DM |
---|
372 | 372 | default n |
---|
373 | 373 | select DM_PERSISTENT_DATA |
---|
374 | 374 | select DM_BIO_PRISON |
---|
375 | | - ---help--- |
---|
376 | | - dm-era tracks which parts of a block device are written to |
---|
377 | | - over time. Useful for maintaining cache coherency when using |
---|
378 | | - vendor snapshots. |
---|
| 375 | + help |
---|
| 376 | + dm-era tracks which parts of a block device are written to |
---|
| 377 | + over time. Useful for maintaining cache coherency when using |
---|
| 378 | + vendor snapshots. |
---|
| 379 | + |
---|
| 380 | +config DM_CLONE |
---|
| 381 | + tristate "Clone target (EXPERIMENTAL)" |
---|
| 382 | + depends on BLK_DEV_DM |
---|
| 383 | + default n |
---|
| 384 | + select DM_PERSISTENT_DATA |
---|
| 385 | + help |
---|
| 386 | + dm-clone produces a one-to-one copy of an existing, read-only source |
---|
| 387 | + device into a writable destination device. The cloned device is |
---|
| 388 | + visible/mountable immediately and the copy of the source device to the |
---|
| 389 | + destination device happens in the background, in parallel with user |
---|
| 390 | + I/O. |
---|
| 391 | + |
---|
| 392 | + If unsure, say N. |
---|
379 | 393 | |
---|
380 | 394 | config DM_MIRROR |
---|
381 | 395 | tristate "Mirror target" |
---|
382 | 396 | depends on BLK_DEV_DM |
---|
383 | | - ---help--- |
---|
384 | | - Allow volume managers to mirror logical volumes, also |
---|
385 | | - needed for live data migration tools such as 'pvmove'. |
---|
| 397 | + help |
---|
| 398 | + Allow volume managers to mirror logical volumes, also |
---|
| 399 | + needed for live data migration tools such as 'pvmove'. |
---|
386 | 400 | |
---|
387 | 401 | config DM_LOG_USERSPACE |
---|
388 | 402 | tristate "Mirror userspace logging" |
---|
389 | 403 | depends on DM_MIRROR && NET |
---|
390 | 404 | select CONNECTOR |
---|
391 | | - ---help--- |
---|
| 405 | + help |
---|
392 | 406 | The userspace logging module provides a mechanism for |
---|
393 | 407 | relaying the dm-dirty-log API to userspace. Log designs |
---|
394 | 408 | which are more suited to userspace implementation (e.g. |
---|
.. | .. |
---|
403 | 417 | select MD_RAID10 |
---|
404 | 418 | select MD_RAID456 |
---|
405 | 419 | select BLK_DEV_MD |
---|
406 | | - ---help--- |
---|
| 420 | + help |
---|
407 | 421 | A dm target that supports RAID1, RAID10, RAID4, RAID5 and RAID6 mappings |
---|
408 | 422 | |
---|
409 | 423 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
---|
.. | .. |
---|
425 | 439 | config DM_ZERO |
---|
426 | 440 | tristate "Zero target" |
---|
427 | 441 | depends on BLK_DEV_DM |
---|
428 | | - ---help--- |
---|
| 442 | + help |
---|
429 | 443 | A target that discards writes, and returns all zeroes for |
---|
430 | 444 | reads. Useful in some recovery situations. |
---|
431 | 445 | |
---|
.. | .. |
---|
437 | 451 | # it is, DM_MULTIPATH must depend on it. We get a build |
---|
438 | 452 | # error if SCSI_DH=m and DM_MULTIPATH=y |
---|
439 | 453 | depends on !SCSI_DH || SCSI |
---|
440 | | - ---help--- |
---|
| 454 | + help |
---|
441 | 455 | Allow volume managers to support multipath hardware. |
---|
442 | 456 | |
---|
443 | 457 | config DM_MULTIPATH_QL |
---|
444 | 458 | tristate "I/O Path Selector based on the number of in-flight I/Os" |
---|
445 | 459 | depends on DM_MULTIPATH |
---|
446 | | - ---help--- |
---|
| 460 | + help |
---|
447 | 461 | This path selector is a dynamic load balancer which selects |
---|
448 | 462 | the path with the least number of in-flight I/Os. |
---|
449 | 463 | |
---|
.. | .. |
---|
452 | 466 | config DM_MULTIPATH_ST |
---|
453 | 467 | tristate "I/O Path Selector based on the service time" |
---|
454 | 468 | depends on DM_MULTIPATH |
---|
455 | | - ---help--- |
---|
| 469 | + help |
---|
456 | 470 | This path selector is a dynamic load balancer which selects |
---|
457 | 471 | the path expected to complete the incoming I/O in the shortest |
---|
458 | 472 | time. |
---|
459 | 473 | |
---|
460 | 474 | If unsure, say N. |
---|
461 | 475 | |
---|
| 476 | +config DM_MULTIPATH_HST |
---|
| 477 | + tristate "I/O Path Selector based on historical service time" |
---|
| 478 | + depends on DM_MULTIPATH |
---|
| 479 | + help |
---|
| 480 | + This path selector is a dynamic load balancer which selects |
---|
| 481 | + the path expected to complete the incoming I/O in the shortest |
---|
| 482 | + time by comparing estimated service time (based on historical |
---|
| 483 | + service time). |
---|
| 484 | + |
---|
| 485 | + If unsure, say N. |
---|
| 486 | + |
---|
462 | 487 | config DM_DELAY |
---|
463 | 488 | tristate "I/O delaying target" |
---|
464 | 489 | depends on BLK_DEV_DM |
---|
465 | | - ---help--- |
---|
| 490 | + help |
---|
466 | 491 | A target that delays reads and/or writes and can send |
---|
467 | 492 | them to different devices. Useful for testing. |
---|
| 493 | + |
---|
| 494 | + If unsure, say N. |
---|
| 495 | + |
---|
| 496 | +config DM_DUST |
---|
| 497 | + tristate "Bad sector simulation target" |
---|
| 498 | + depends on BLK_DEV_DM |
---|
| 499 | + help |
---|
| 500 | + A target that simulates bad sector behavior. |
---|
| 501 | + Useful for testing. |
---|
| 502 | + |
---|
| 503 | + If unsure, say N. |
---|
| 504 | + |
---|
| 505 | +config DM_INIT |
---|
| 506 | + bool "DM \"dm-mod.create=\" parameter support" |
---|
| 507 | + depends on BLK_DEV_DM=y |
---|
| 508 | + help |
---|
| 509 | + Enable "dm-mod.create=" parameter to create mapped devices at init time. |
---|
| 510 | + This option is useful to allow mounting rootfs without requiring an |
---|
| 511 | + initramfs. |
---|
| 512 | + See Documentation/admin-guide/device-mapper/dm-init.rst for dm-mod.create="..." |
---|
| 513 | + format. |
---|
468 | 514 | |
---|
469 | 515 | If unsure, say N. |
---|
470 | 516 | |
---|
471 | 517 | config DM_UEVENT |
---|
472 | 518 | bool "DM uevents" |
---|
473 | 519 | depends on BLK_DEV_DM |
---|
474 | | - ---help--- |
---|
| 520 | + help |
---|
475 | 521 | Generate udev events for DM events. |
---|
476 | 522 | |
---|
477 | 523 | config DM_FLAKEY |
---|
478 | 524 | tristate "Flakey target" |
---|
479 | 525 | depends on BLK_DEV_DM |
---|
480 | | - ---help--- |
---|
481 | | - A target that intermittently fails I/O for debugging purposes. |
---|
| 526 | + help |
---|
| 527 | + A target that intermittently fails I/O for debugging purposes. |
---|
482 | 528 | |
---|
483 | 529 | config DM_VERITY |
---|
484 | 530 | tristate "Verity target support" |
---|
.. | .. |
---|
486 | 532 | select CRYPTO |
---|
487 | 533 | select CRYPTO_HASH |
---|
488 | 534 | select DM_BUFIO |
---|
489 | | - ---help--- |
---|
| 535 | + help |
---|
490 | 536 | This device-mapper target creates a read-only device that |
---|
491 | 537 | transparently validates the data on one underlying device against |
---|
492 | 538 | a pre-generated tree of cryptographic checksums stored on a second |
---|
.. | .. |
---|
500 | 546 | |
---|
501 | 547 | If unsure, say N. |
---|
502 | 548 | |
---|
503 | | -config DM_VERITY_AVB |
---|
504 | | - tristate "Support AVB specific verity error behavior" |
---|
| 549 | +config DM_VERITY_VERIFY_ROOTHASH_SIG |
---|
| 550 | + def_bool n |
---|
| 551 | + bool "Verity data device root hash signature verification support" |
---|
505 | 552 | depends on DM_VERITY |
---|
506 | | - ---help--- |
---|
507 | | - Enables Android Verified Boot platform-specific error |
---|
508 | | - behavior. In particular, it will modify the vbmeta partition |
---|
509 | | - specified on the kernel command-line when non-transient error |
---|
510 | | - occurs (followed by a panic). |
---|
| 553 | + select SYSTEM_DATA_VERIFICATION |
---|
| 554 | + help |
---|
| 555 | + Add ability for dm-verity device to be validated if the |
---|
| 556 | + pre-generated tree of cryptographic checksums passed has a pkcs#7 |
---|
| 557 | + signature file that can validate the roothash of the tree. |
---|
| 558 | + |
---|
| 559 | + If unsure, say N. |
---|
511 | 560 | |
---|
512 | 561 | config DM_VERITY_FEC |
---|
513 | 562 | bool "Verity forward error correction support" |
---|
514 | 563 | depends on DM_VERITY |
---|
515 | 564 | select REED_SOLOMON |
---|
516 | 565 | select REED_SOLOMON_DEC8 |
---|
517 | | - ---help--- |
---|
| 566 | + help |
---|
518 | 567 | Add forward error correction support to dm-verity. This option |
---|
519 | 568 | makes it possible to use pre-generated error correction data to |
---|
520 | 569 | recover from corrupted blocks. |
---|
.. | .. |
---|
524 | 573 | config DM_SWITCH |
---|
525 | 574 | tristate "Switch target support (EXPERIMENTAL)" |
---|
526 | 575 | depends on BLK_DEV_DM |
---|
527 | | - ---help--- |
---|
| 576 | + help |
---|
528 | 577 | This device-mapper target creates a device that supports an arbitrary |
---|
529 | 578 | mapping of fixed-size regions of I/O across a fixed set of paths. |
---|
530 | 579 | The path used for any specific region can be switched dynamically |
---|
.. | .. |
---|
538 | 587 | config DM_LOG_WRITES |
---|
539 | 588 | tristate "Log writes target support" |
---|
540 | 589 | depends on BLK_DEV_DM |
---|
541 | | - ---help--- |
---|
| 590 | + help |
---|
542 | 591 | This device-mapper target takes two devices, one device to use |
---|
543 | 592 | normally, one to log all write operations done to the first device. |
---|
544 | 593 | This is for use by file system developers wishing to verify that |
---|
.. | .. |
---|
557 | 606 | select BLK_DEV_INTEGRITY |
---|
558 | 607 | select DM_BUFIO |
---|
559 | 608 | select CRYPTO |
---|
| 609 | + select CRYPTO_SKCIPHER |
---|
560 | 610 | select ASYNC_XOR |
---|
561 | | - ---help--- |
---|
| 611 | + help |
---|
562 | 612 | This device-mapper target emulates a block device that has |
---|
563 | 613 | additional per-sector tags that can be used for storing |
---|
564 | 614 | integrity information. |
---|
.. | .. |
---|
574 | 624 | tristate "Drive-managed zoned block device target support" |
---|
575 | 625 | depends on BLK_DEV_DM |
---|
576 | 626 | depends on BLK_DEV_ZONED |
---|
577 | | - ---help--- |
---|
| 627 | + select CRC32 |
---|
| 628 | + help |
---|
578 | 629 | This device-mapper target takes a host-managed or host-aware zoned |
---|
579 | 630 | block device and exposes most of its capacity as a regular block |
---|
580 | 631 | device (drive-managed zoned block device) without any write |
---|
.. | .. |
---|
593 | 644 | tristate "Backup block device" |
---|
594 | 645 | depends on BLK_DEV_DM |
---|
595 | 646 | select DM_BUFIO |
---|
596 | | - ---help--- |
---|
| 647 | + help |
---|
597 | 648 | This device-mapper target takes a device and keeps a log of all |
---|
598 | 649 | changes using free blocks identified by issuing a trim command. |
---|
599 | 650 | This can then be restored by running a command line utility, |
---|
600 | 651 | or committed by simply replacing the target. |
---|
601 | | - |
---|
602 | | - If unsure, say N. |
---|
603 | | - |
---|
604 | | -config DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED |
---|
605 | | - bool "Verity will validate blocks at most once" |
---|
606 | | - depends on DM_VERITY |
---|
607 | | - ---help--- |
---|
608 | | - Default enables at_most_once option for dm-verity |
---|
609 | | - |
---|
610 | | - Verify data blocks only the first time they are read from the |
---|
611 | | - data device, rather than every time. This reduces the overhead |
---|
612 | | - of dm-verity so that it can be used on systems that are memory |
---|
613 | | - and/or CPU constrained. However, it provides a reduced level |
---|
614 | | - of security because only offline tampering of the data device's |
---|
615 | | - content will be detected, not online tampering. |
---|
616 | | - |
---|
617 | | - Hash blocks are still verified each time they are read from the |
---|
618 | | - hash device, since verification of hash blocks is less performance |
---|
619 | | - critical than data blocks, and a hash block will not be verified |
---|
620 | | - any more after all the data blocks it covers have been verified anyway. |
---|
621 | 652 | |
---|
622 | 653 | If unsure, say N. |
---|
623 | 654 | |
---|