| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | # |
| 3 | # Block device driver configuration |
| 4 | # |
| 5 | |
| 6 | menuconfig MD |
| 7 | bool "Multiple devices driver support (RAID and LVM)" |
| 8 | depends on BLOCK |
| 9 | help |
| 10 | Support multiple physical spindles through a single logical device. |
| 11 | Required for RAID and logical volume management. |
| 12 | |
| 13 | if MD |
| 14 | |
| 15 | config BLK_DEV_MD |
| 16 | tristate "RAID support" |
| 17 | select BLOCK_HOLDER_DEPRECATED if SYSFS |
| 18 | select BUFFER_HEAD |
| 19 | # BLOCK_LEGACY_AUTOLOAD requirement should be removed |
| 20 | # after relevant mdadm enhancements - to make "names=yes" |
| 21 | # the default - are widely available. |
| 22 | select BLOCK_LEGACY_AUTOLOAD |
| 23 | help |
| 24 | This driver lets you combine several hard disk partitions into one |
| 25 | logical block device. This can be used to simply append one |
| 26 | partition to another one or to combine several redundant hard disks |
| 27 | into a RAID1/4/5 device so as to provide protection against hard |
| 28 | disk failures. This is called "Software RAID" since the combining of |
| 29 | the partitions is done by the kernel. "Hardware RAID" means that the |
| 30 | combining is done by a dedicated controller; if you have such a |
| 31 | controller, you do not need to say Y here. |
| 32 | |
| 33 | More information about Software RAID on Linux is contained in the |
| 34 | Software RAID mini-HOWTO, available from |
| 35 | <https://www.tldp.org/docs.html#howto>. There you will also learn |
| 36 | where to get the supporting user space utilities raidtools. |
| 37 | |
| 38 | If unsure, say N. |
| 39 | |
| 40 | config MD_BITMAP |
| 41 | bool "MD RAID bitmap support" |
| 42 | default y |
| 43 | depends on BLK_DEV_MD |
| 44 | help |
| 45 | If you say Y here, support for the write intent bitmap will be |
| 46 | enabled. The bitmap can be used to optimize resync speed after power |
| 47 | failure or readding a disk, limiting it to recorded dirty sectors in |
| 48 | bitmap. |
| 49 | |
| 50 | This feature can be added to existing MD array or MD array can be |
| 51 | created with bitmap via mdadm(8). |
| 52 | |
| 53 | If unsure, say Y. |
| 54 | |
| 55 | config MD_LLBITMAP |
| 56 | bool "MD RAID lockless bitmap support" |
| 57 | depends on BLK_DEV_MD |
| 58 | help |
| 59 | If you say Y here, support for the lockless write intent bitmap will |
| 60 | be enabled. |
| 61 | |
| 62 | Note, this is an experimental feature. |
| 63 | |
| 64 | If unsure, say N. |
| 65 | |
| 66 | config MD_AUTODETECT |
| 67 | bool "Autodetect RAID arrays during kernel boot" |
| 68 | depends on BLK_DEV_MD=y |
| 69 | default y |
| 70 | help |
| 71 | If you say Y here, then the kernel will try to autodetect raid |
| 72 | arrays as part of its boot process. |
| 73 | |
| 74 | If you don't use raid and say Y, this autodetection can cause |
| 75 | a several-second delay in the boot time due to various |
| 76 | synchronisation steps that are part of this step. |
| 77 | |
| 78 | If unsure, say Y. |
| 79 | |
| 80 | config MD_BITMAP_FILE |
| 81 | bool "MD bitmap file support (deprecated)" |
| 82 | default y |
| 83 | depends on MD_BITMAP |
| 84 | help |
| 85 | If you say Y here, support for write intent bitmaps in files on an |
| 86 | external file system is enabled. This is an alternative to the internal |
| 87 | bitmaps near the MD superblock, and very problematic code that abuses |
| 88 | various kernel APIs and can only work with files on a file system not |
| 89 | actually sitting on the MD device. |
| 90 | |
| 91 | config MD_LINEAR |
| 92 | tristate "Linear (append) mode" |
| 93 | depends on BLK_DEV_MD |
| 94 | help |
| 95 | If you say Y here, then your multiple devices driver will be able to |
| 96 | use the so-called linear mode, i.e. it will combine the hard disk |
| 97 | partitions by simply appending one to the other. |
| 98 | |
| 99 | To compile this as a module, choose M here: the module |
| 100 | will be called linear. |
| 101 | |
| 102 | If unsure, say Y. |
| 103 | |
| 104 | config MD_RAID0 |
| 105 | tristate "RAID-0 (striping) mode" |
| 106 | depends on BLK_DEV_MD |
| 107 | help |
| 108 | If you say Y here, then your multiple devices driver will be able to |
| 109 | use the so-called raid0 mode, i.e. it will combine the hard disk |
| 110 | partitions into one logical device in such a fashion as to fill them |
| 111 | up evenly, one chunk here and one chunk there. This will increase |
| 112 | the throughput rate if the partitions reside on distinct disks. |
| 113 | |
| 114 | Information about Software RAID on Linux is contained in the |
| 115 | Software-RAID mini-HOWTO, available from |
| 116 | <https://www.tldp.org/docs.html#howto>. There you will also |
| 117 | learn where to get the supporting user space utilities raidtools. |
| 118 | |
| 119 | To compile this as a module, choose M here: the module |
| 120 | will be called raid0. |
| 121 | |
| 122 | If unsure, say Y. |
| 123 | |
| 124 | config MD_RAID1 |
| 125 | tristate "RAID-1 (mirroring) mode" |
| 126 | depends on BLK_DEV_MD |
| 127 | help |
| 128 | A RAID-1 set consists of several disk drives which are exact copies |
| 129 | of each other. In the event of a mirror failure, the RAID driver |
| 130 | will continue to use the operational mirrors in the set, providing |
| 131 | an error free MD (multiple device) to the higher levels of the |
| 132 | kernel. In a set with N drives, the available space is the capacity |
| 133 | of a single drive, and the set protects against a failure of (N - 1) |
| 134 | drives. |
| 135 | |
| 136 | Information about Software RAID on Linux is contained in the |
| 137 | Software-RAID mini-HOWTO, available from |
| 138 | <https://www.tldp.org/docs.html#howto>. There you will also |
| 139 | learn where to get the supporting user space utilities raidtools. |
| 140 | |
| 141 | If you want to use such a RAID-1 set, say Y. To compile this code |
| 142 | as a module, choose M here: the module will be called raid1. |
| 143 | |
| 144 | If unsure, say Y. |
| 145 | |
| 146 | config MD_RAID10 |
| 147 | tristate "RAID-10 (mirrored striping) mode" |
| 148 | depends on BLK_DEV_MD |
| 149 | help |
| 150 | RAID-10 provides a combination of striping (RAID-0) and |
| 151 | mirroring (RAID-1) with easier configuration and more flexible |
| 152 | layout. |
| 153 | Unlike RAID-0, but like RAID-1, RAID-10 requires all devices to |
| 154 | be the same size (or at least, only as much as the smallest device |
| 155 | will be used). |
| 156 | RAID-10 provides a variety of layouts that provide different levels |
| 157 | of redundancy and performance. |
| 158 | |
| 159 | RAID-10 requires mdadm-1.7.0 or later, available at: |
| 160 | |
| 161 | https://www.kernel.org/pub/linux/utils/raid/mdadm/ |
| 162 | |
| 163 | If unsure, say Y. |
| 164 | |
| 165 | config MD_RAID456 |
| 166 | tristate "RAID-4/RAID-5/RAID-6 mode" |
| 167 | depends on BLK_DEV_MD |
| 168 | select RAID6_PQ |
| 169 | select CRC32 |
| 170 | select ASYNC_MEMCPY |
| 171 | select ASYNC_XOR |
| 172 | select ASYNC_PQ |
| 173 | select ASYNC_RAID6_RECOV |
| 174 | help |
| 175 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 176 | the capacity of C * (N - 1) MB, and protects against a failure |
| 177 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 178 | contain data sectors, and one drive contains the parity protection. |
| 179 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 180 | while a RAID-5 set distributes the parity across the drives in one |
| 181 | of the available parity distribution methods. |
| 182 | |
| 183 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 184 | provides the capacity of C * (N - 2) MB, and protects |
| 185 | against a failure of any two drives. For a given sector |
| 186 | (row) number, (N - 2) drives contain data sectors, and two |
| 187 | drives contains two independent redundancy syndromes. Like |
| 188 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 189 | in one of the available parity distribution methods. |
| 190 | |
| 191 | Information about Software RAID on Linux is contained in the |
| 192 | Software-RAID mini-HOWTO, available from |
| 193 | <https://www.tldp.org/docs.html#howto>. There you will also |
| 194 | learn where to get the supporting user space utilities raidtools. |
| 195 | |
| 196 | If you want to use such a RAID-4/RAID-5/RAID-6 set, say Y. To |
| 197 | compile this code as a module, choose M here: the module |
| 198 | will be called raid456. |
| 199 | |
| 200 | If unsure, say Y. |
| 201 | |
| 202 | config MD_CLUSTER |
| 203 | tristate "Cluster Support for MD" |
| 204 | select MD_BITMAP |
| 205 | depends on BLK_DEV_MD |
| 206 | depends on DLM |
| 207 | default n |
| 208 | help |
| 209 | Clustering support for MD devices. This enables locking and |
| 210 | synchronization across multiple systems on the cluster, so all |
| 211 | nodes in the cluster can access the MD devices simultaneously. |
| 212 | |
| 213 | This brings the redundancy (and uptime) of RAID levels across the |
| 214 | nodes of the cluster. Currently, it can work with raid1 and raid10 |
| 215 | (limited support). |
| 216 | |
| 217 | If unsure, say N. |
| 218 | |
| 219 | source "drivers/md/bcache/Kconfig" |
| 220 | |
| 221 | config BLK_DEV_DM_BUILTIN |
| 222 | bool |
| 223 | |
| 224 | config BLK_DEV_DM |
| 225 | tristate "Device mapper support" |
| 226 | select BLOCK_HOLDER_DEPRECATED if SYSFS |
| 227 | select BLK_DEV_DM_BUILTIN |
| 228 | select BLK_MQ_STACKING |
| 229 | select CRYPTO_LIB_SHA256 if IMA |
| 230 | depends on DAX || DAX=n |
| 231 | help |
| 232 | Device-mapper is a low level volume manager. It works by allowing |
| 233 | people to specify mappings for ranges of logical sectors. Various |
| 234 | mapping types are available, in addition people may write their own |
| 235 | modules containing custom mappings if they wish. |
| 236 | |
| 237 | Higher level volume managers such as LVM2 use this driver. |
| 238 | |
| 239 | To compile this as a module, choose M here: the module will be |
| 240 | called dm-mod. |
| 241 | |
| 242 | If unsure, say N. |
| 243 | |
| 244 | config DM_DEBUG |
| 245 | bool "Device mapper debugging support" |
| 246 | depends on BLK_DEV_DM |
| 247 | help |
| 248 | Enable this for messages that may help debug device-mapper problems. |
| 249 | |
| 250 | If unsure, say N. |
| 251 | |
| 252 | config DM_BUFIO |
| 253 | tristate |
| 254 | depends on BLK_DEV_DM |
| 255 | help |
| 256 | This interface allows you to do buffered I/O on a device and acts |
| 257 | as a cache, holding recently-read blocks in memory and performing |
| 258 | delayed writes. |
| 259 | |
| 260 | config DM_DEBUG_BLOCK_MANAGER_LOCKING |
| 261 | bool "Block manager locking" |
| 262 | depends on DM_BUFIO |
| 263 | help |
| 264 | Block manager locking can catch various metadata corruption issues. |
| 265 | |
| 266 | If unsure, say N. |
| 267 | |
| 268 | config DM_DEBUG_BLOCK_STACK_TRACING |
| 269 | bool "Keep stack trace of persistent data block lock holders" |
| 270 | depends on STACKTRACE_SUPPORT && DM_DEBUG_BLOCK_MANAGER_LOCKING |
| 271 | select STACKTRACE |
| 272 | help |
| 273 | Enable this for messages that may help debug problems with the |
| 274 | block manager locking used by thin provisioning and caching. |
| 275 | |
| 276 | If unsure, say N. |
| 277 | |
| 278 | config DM_BIO_PRISON |
| 279 | tristate |
| 280 | depends on BLK_DEV_DM |
| 281 | help |
| 282 | Some bio locking schemes used by other device-mapper targets |
| 283 | including thin provisioning. |
| 284 | |
| 285 | source "drivers/md/persistent-data/Kconfig" |
| 286 | |
| 287 | config DM_UNSTRIPED |
| 288 | tristate "Unstriped target" |
| 289 | depends on BLK_DEV_DM |
| 290 | help |
| 291 | Unstripes I/O so it is issued solely on a single drive in a HW |
| 292 | RAID0 or dm-striped target. |
| 293 | |
| 294 | config DM_CRYPT |
| 295 | tristate "Crypt target support" |
| 296 | depends on BLK_DEV_DM |
| 297 | depends on (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n) |
| 298 | depends on (TRUSTED_KEYS || TRUSTED_KEYS=n) |
| 299 | select CRC32 |
| 300 | select CRYPTO |
| 301 | select CRYPTO_CBC |
| 302 | select CRYPTO_ESSIV |
| 303 | select CRYPTO_LIB_AES |
| 304 | select CRYPTO_LIB_MD5 # needed by lmk IV mode |
| 305 | help |
| 306 | This device-mapper target allows you to create a device that |
| 307 | transparently encrypts the data on it. You'll need to activate |
| 308 | the ciphers you're going to use in the cryptoapi configuration. |
| 309 | |
| 310 | For further information on dm-crypt and userspace tools see: |
| 311 | <https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt> |
| 312 | |
| 313 | To compile this code as a module, choose M here: the module will |
| 314 | be called dm-crypt. |
| 315 | |
| 316 | If unsure, say N. |
| 317 | |
| 318 | config DM_INLINECRYPT |
| 319 | tristate "Inline encryption target support" |
| 320 | depends on BLK_DEV_DM |
| 321 | depends on (KEYS || KEYS=n) |
| 322 | depends on BLK_INLINE_ENCRYPTION |
| 323 | help |
| 324 | This device-mapper target is similar to dm-crypt, but it uses the |
| 325 | blk-crypto API instead of the regular crypto API. This allows it to |
| 326 | take advantage of inline encryption hardware such as that commonly |
| 327 | built into UFS host controllers. |
| 328 | |
| 329 | config DM_SNAPSHOT |
| 330 | tristate "Snapshot target" |
| 331 | depends on BLK_DEV_DM |
| 332 | select DM_BUFIO |
| 333 | help |
| 334 | Allow volume managers to take writable snapshots of a device. |
| 335 | |
| 336 | config DM_THIN_PROVISIONING |
| 337 | tristate "Thin provisioning target" |
| 338 | depends on BLK_DEV_DM |
| 339 | select DM_PERSISTENT_DATA |
| 340 | select DM_BIO_PRISON |
| 341 | help |
| 342 | Provides thin provisioning and snapshots that share a data store. |
| 343 | |
| 344 | config DM_CACHE |
| 345 | tristate "Cache target (EXPERIMENTAL)" |
| 346 | depends on BLK_DEV_DM |
| 347 | default n |
| 348 | select DM_PERSISTENT_DATA |
| 349 | select DM_BIO_PRISON |
| 350 | help |
| 351 | dm-cache attempts to improve performance of a block device by |
| 352 | moving frequently used data to a smaller, higher performance |
| 353 | device. Different 'policy' plugins can be used to change the |
| 354 | algorithms used to select which blocks are promoted, demoted, |
| 355 | cleaned etc. It supports writeback and writethrough modes. |
| 356 | |
| 357 | config DM_CACHE_SMQ |
| 358 | tristate "Stochastic MQ Cache Policy (EXPERIMENTAL)" |
| 359 | depends on DM_CACHE |
| 360 | default y |
| 361 | help |
| 362 | A cache policy that uses a multiqueue ordered by recent hits |
| 363 | to select which blocks should be promoted and demoted. |
| 364 | This is meant to be a general purpose policy. It prioritises |
| 365 | reads over writes. This SMQ policy (vs MQ) offers the promise |
| 366 | of less memory utilization, improved performance and increased |
| 367 | adaptability in the face of changing workloads. |
| 368 | |
| 369 | config DM_WRITECACHE |
| 370 | tristate "Writecache target" |
| 371 | depends on BLK_DEV_DM |
| 372 | help |
| 373 | The writecache target caches writes on persistent memory or SSD. |
| 374 | It is intended for databases or other programs that need extremely |
| 375 | low commit latency. |
| 376 | |
| 377 | The writecache target doesn't cache reads because reads are supposed |
| 378 | to be cached in standard RAM. |
| 379 | |
| 380 | config DM_EBS |
| 381 | tristate "Emulated block size target (EXPERIMENTAL)" |
| 382 | depends on BLK_DEV_DM && !HIGHMEM |
| 383 | select DM_BUFIO |
| 384 | help |
| 385 | dm-ebs emulates smaller logical block size on backing devices |
| 386 | with larger ones (e.g. 512 byte sectors on 4K native disks). |
| 387 | |
| 388 | config DM_ERA |
| 389 | tristate "Era target (EXPERIMENTAL)" |
| 390 | depends on BLK_DEV_DM |
| 391 | default n |
| 392 | select DM_PERSISTENT_DATA |
| 393 | select DM_BIO_PRISON |
| 394 | help |
| 395 | dm-era tracks which parts of a block device are written to |
| 396 | over time. Useful for maintaining cache coherency when using |
| 397 | vendor snapshots. |
| 398 | |
| 399 | config DM_CLONE |
| 400 | tristate "Clone target (EXPERIMENTAL)" |
| 401 | depends on BLK_DEV_DM |
| 402 | default n |
| 403 | select DM_PERSISTENT_DATA |
| 404 | help |
| 405 | dm-clone produces a one-to-one copy of an existing, read-only source |
| 406 | device into a writable destination device. The cloned device is |
| 407 | visible/mountable immediately and the copy of the source device to the |
| 408 | destination device happens in the background, in parallel with user |
| 409 | I/O. |
| 410 | |
| 411 | If unsure, say N. |
| 412 | |
| 413 | config DM_MIRROR |
| 414 | tristate "Mirror target" |
| 415 | depends on BLK_DEV_DM |
| 416 | help |
| 417 | Allow volume managers to mirror logical volumes, also |
| 418 | needed for live data migration tools such as 'pvmove'. |
| 419 | |
| 420 | config DM_LOG_USERSPACE |
| 421 | tristate "Mirror userspace logging" |
| 422 | depends on DM_MIRROR && NET |
| 423 | select CONNECTOR |
| 424 | help |
| 425 | The userspace logging module provides a mechanism for |
| 426 | relaying the dm-dirty-log API to userspace. Log designs |
| 427 | which are more suited to userspace implementation (e.g. |
| 428 | shared storage logs) or experimental logs can be implemented |
| 429 | by leveraging this framework. |
| 430 | |
| 431 | config DM_RAID |
| 432 | tristate "RAID 1/4/5/6/10 target" |
| 433 | depends on BLK_DEV_DM |
| 434 | select MD_RAID0 |
| 435 | select MD_RAID1 |
| 436 | select MD_RAID10 |
| 437 | select MD_RAID456 |
| 438 | select MD_BITMAP |
| 439 | select BLK_DEV_MD |
| 440 | help |
| 441 | A dm target that supports RAID1, RAID10, RAID4, RAID5 and RAID6 mappings |
| 442 | |
| 443 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 444 | the capacity of C * (N - 1) MB, and protects against a failure |
| 445 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 446 | contain data sectors, and one drive contains the parity protection. |
| 447 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 448 | while a RAID-5 set distributes the parity across the drives in one |
| 449 | of the available parity distribution methods. |
| 450 | |
| 451 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 452 | provides the capacity of C * (N - 2) MB, and protects |
| 453 | against a failure of any two drives. For a given sector |
| 454 | (row) number, (N - 2) drives contain data sectors, and two |
| 455 | drives contains two independent redundancy syndromes. Like |
| 456 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 457 | in one of the available parity distribution methods. |
| 458 | |
| 459 | config DM_ZERO |
| 460 | tristate "Zero target" |
| 461 | depends on BLK_DEV_DM |
| 462 | help |
| 463 | A target that discards writes, and returns all zeroes for |
| 464 | reads. Useful in some recovery situations. |
| 465 | |
| 466 | config DM_MULTIPATH |
| 467 | tristate "Multipath target" |
| 468 | depends on BLK_DEV_DM |
| 469 | # nasty syntax but means make DM_MULTIPATH independent |
| 470 | # of SCSI_DH if the latter isn't defined but if |
| 471 | # it is, DM_MULTIPATH must depend on it. We get a build |
| 472 | # error if SCSI_DH=m and DM_MULTIPATH=y |
| 473 | depends on !SCSI_DH || SCSI |
| 474 | help |
| 475 | Allow volume managers to support multipath hardware. |
| 476 | |
| 477 | config DM_MULTIPATH_QL |
| 478 | tristate "I/O Path Selector based on the number of in-flight I/Os" |
| 479 | depends on DM_MULTIPATH |
| 480 | help |
| 481 | This path selector is a dynamic load balancer which selects |
| 482 | the path with the least number of in-flight I/Os. |
| 483 | |
| 484 | If unsure, say N. |
| 485 | |
| 486 | config DM_MULTIPATH_ST |
| 487 | tristate "I/O Path Selector based on the service time" |
| 488 | depends on DM_MULTIPATH |
| 489 | help |
| 490 | This path selector is a dynamic load balancer which selects |
| 491 | the path expected to complete the incoming I/O in the shortest |
| 492 | time. |
| 493 | |
| 494 | If unsure, say N. |
| 495 | |
| 496 | config DM_MULTIPATH_HST |
| 497 | tristate "I/O Path Selector based on historical service time" |
| 498 | depends on DM_MULTIPATH |
| 499 | help |
| 500 | This path selector is a dynamic load balancer which selects |
| 501 | the path expected to complete the incoming I/O in the shortest |
| 502 | time by comparing estimated service time (based on historical |
| 503 | service time). |
| 504 | |
| 505 | If unsure, say N. |
| 506 | |
| 507 | config DM_MULTIPATH_IOA |
| 508 | tristate "I/O Path Selector based on CPU submission" |
| 509 | depends on DM_MULTIPATH |
| 510 | help |
| 511 | This path selector selects the path based on the CPU the IO is |
| 512 | executed on and the CPU to path mapping setup at path addition time. |
| 513 | |
| 514 | If unsure, say N. |
| 515 | |
| 516 | config DM_DELAY |
| 517 | tristate "I/O delaying target" |
| 518 | depends on BLK_DEV_DM |
| 519 | help |
| 520 | A target that delays reads and/or writes and can send |
| 521 | them to different devices. Useful for testing. |
| 522 | |
| 523 | If unsure, say N. |
| 524 | |
| 525 | config DM_DUST |
| 526 | tristate "Bad sector simulation target" |
| 527 | depends on BLK_DEV_DM |
| 528 | help |
| 529 | A target that simulates bad sector behavior. |
| 530 | Useful for testing. |
| 531 | |
| 532 | If unsure, say N. |
| 533 | |
| 534 | config DM_INIT |
| 535 | bool "DM \"dm-mod.create=\" parameter support" |
| 536 | depends on BLK_DEV_DM=y |
| 537 | help |
| 538 | Enable "dm-mod.create=" parameter to create mapped devices at init time. |
| 539 | This option is useful to allow mounting rootfs without requiring an |
| 540 | initramfs. |
| 541 | See Documentation/admin-guide/device-mapper/dm-init.rst for dm-mod.create="..." |
| 542 | format. |
| 543 | |
| 544 | If unsure, say N. |
| 545 | |
| 546 | config DM_UEVENT |
| 547 | bool "DM uevents" |
| 548 | depends on BLK_DEV_DM |
| 549 | help |
| 550 | Generate udev events for DM events. |
| 551 | |
| 552 | config DM_FLAKEY |
| 553 | tristate "Flakey target" |
| 554 | depends on BLK_DEV_DM |
| 555 | help |
| 556 | A target that intermittently fails I/O for debugging purposes. |
| 557 | |
| 558 | config DM_VERITY |
| 559 | tristate "Verity target support" |
| 560 | depends on BLK_DEV_DM |
| 561 | select CRYPTO |
| 562 | select CRYPTO_HASH |
| 563 | select CRYPTO_LIB_SHA256 |
| 564 | select DM_BUFIO |
| 565 | select REED_SOLOMON if DM_VERITY_FEC |
| 566 | select REED_SOLOMON_DEC8 if DM_VERITY_FEC |
| 567 | help |
| 568 | This device-mapper target creates a read-only device that |
| 569 | transparently validates the data on one underlying device against |
| 570 | a pre-generated tree of cryptographic checksums stored on a second |
| 571 | device. |
| 572 | |
| 573 | You'll need to activate the digests you're going to use in the |
| 574 | cryptoapi configuration. |
| 575 | |
| 576 | To compile this code as a module, choose M here: the module will |
| 577 | be called dm-verity. |
| 578 | |
| 579 | If unsure, say N. |
| 580 | |
| 581 | config DM_VERITY_VERIFY_ROOTHASH_SIG |
| 582 | bool "Verity data device root hash signature verification support" |
| 583 | depends on DM_VERITY |
| 584 | select SYSTEM_DATA_VERIFICATION |
| 585 | help |
| 586 | Add ability for dm-verity device to be validated if the |
| 587 | pre-generated tree of cryptographic checksums passed has a pkcs#7 |
| 588 | signature file that can validate the roothash of the tree. |
| 589 | |
| 590 | By default, rely on the builtin trusted keyring. |
| 591 | |
| 592 | If unsure, say N. |
| 593 | |
| 594 | config DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING |
| 595 | bool "Verity data device root hash signature verification with secondary keyring" |
| 596 | depends on DM_VERITY_VERIFY_ROOTHASH_SIG |
| 597 | depends on SECONDARY_TRUSTED_KEYRING |
| 598 | help |
| 599 | Rely on the secondary trusted keyring to verify dm-verity signatures. |
| 600 | |
| 601 | If unsure, say N. |
| 602 | |
| 603 | config DM_VERITY_VERIFY_ROOTHASH_SIG_PLATFORM_KEYRING |
| 604 | bool "Verity data device root hash signature verification with platform keyring" |
| 605 | default DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING |
| 606 | depends on DM_VERITY_VERIFY_ROOTHASH_SIG |
| 607 | depends on INTEGRITY_PLATFORM_KEYRING |
| 608 | help |
| 609 | Rely also on the platform keyring to verify dm-verity signatures. |
| 610 | |
| 611 | If unsure, say N. |
| 612 | |
| 613 | config DM_VERITY_FEC |
| 614 | bool "Verity forward error correction support" |
| 615 | depends on DM_VERITY |
| 616 | help |
| 617 | Add forward error correction support to dm-verity. This option |
| 618 | makes it possible to use pre-generated error correction data to |
| 619 | recover from corrupted blocks. |
| 620 | |
| 621 | If unsure, say N. |
| 622 | |
| 623 | config DM_SWITCH |
| 624 | tristate "Switch target support (EXPERIMENTAL)" |
| 625 | depends on BLK_DEV_DM |
| 626 | help |
| 627 | This device-mapper target creates a device that supports an arbitrary |
| 628 | mapping of fixed-size regions of I/O across a fixed set of paths. |
| 629 | The path used for any specific region can be switched dynamically |
| 630 | by sending the target a message. |
| 631 | |
| 632 | To compile this code as a module, choose M here: the module will |
| 633 | be called dm-switch. |
| 634 | |
| 635 | If unsure, say N. |
| 636 | |
| 637 | config DM_LOG_WRITES |
| 638 | tristate "Log writes target support" |
| 639 | depends on BLK_DEV_DM |
| 640 | help |
| 641 | This device-mapper target takes two devices, one device to use |
| 642 | normally, one to log all write operations done to the first device. |
| 643 | This is for use by file system developers wishing to verify that |
| 644 | their fs is writing a consistent file system at all times by allowing |
| 645 | them to replay the log in a variety of ways and to check the |
| 646 | contents. |
| 647 | |
| 648 | To compile this code as a module, choose M here: the module will |
| 649 | be called dm-log-writes. |
| 650 | |
| 651 | If unsure, say N. |
| 652 | |
| 653 | config DM_INTEGRITY |
| 654 | tristate "Integrity target support" |
| 655 | depends on BLK_DEV_DM |
| 656 | select BLK_DEV_INTEGRITY |
| 657 | select DM_BUFIO |
| 658 | select CRYPTO |
| 659 | select CRYPTO_SKCIPHER |
| 660 | select ASYNC_XOR |
| 661 | select DM_AUDIT if AUDIT |
| 662 | help |
| 663 | This device-mapper target emulates a block device that has |
| 664 | additional per-sector tags that can be used for storing |
| 665 | integrity information. |
| 666 | |
| 667 | This integrity target is used with the dm-crypt target to |
| 668 | provide authenticated disk encryption or it can be used |
| 669 | standalone. |
| 670 | |
| 671 | To compile this code as a module, choose M here: the module will |
| 672 | be called dm-integrity. |
| 673 | |
| 674 | config DM_ZONED |
| 675 | tristate "Drive-managed zoned block device target support" |
| 676 | depends on BLK_DEV_DM |
| 677 | depends on BLK_DEV_ZONED |
| 678 | select CRC32 |
| 679 | help |
| 680 | This device-mapper target takes a host-managed or host-aware zoned |
| 681 | block device and exposes most of its capacity as a regular block |
| 682 | device (drive-managed zoned block device) without any write |
| 683 | constraints. This is mainly intended for use with file systems that |
| 684 | do not natively support zoned block devices but still want to |
| 685 | benefit from the increased capacity offered by SMR disks. Other uses |
| 686 | by applications using raw block devices (for example object stores) |
| 687 | are also possible. |
| 688 | |
| 689 | To compile this code as a module, choose M here: the module will |
| 690 | be called dm-zoned. |
| 691 | |
| 692 | If unsure, say N. |
| 693 | |
| 694 | config DM_AUDIT |
| 695 | bool "DM audit events" |
| 696 | depends on BLK_DEV_DM |
| 697 | depends on AUDIT |
| 698 | help |
| 699 | Generate audit events for device-mapper. |
| 700 | |
| 701 | Enables audit logging of several security relevant events in the |
| 702 | particular device-mapper targets, especially the integrity target. |
| 703 | |
| 704 | source "drivers/md/dm-vdo/Kconfig" |
| 705 | |
| 706 | source "drivers/md/dm-pcache/Kconfig" |
| 707 | |
| 708 | endif # MD |