1# SPDX-License-Identifier: GPL-2.0-only 2# 3# Block device driver configuration 4# 5 6menuconfig 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 13if MD 14 15config 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 40config 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 55config 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 66config 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 80config 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 91config 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 104config 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 124config 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 146config 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 165config 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 202config 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 219source "drivers/md/bcache/Kconfig" 220 221config BLK_DEV_DM_BUILTIN 222 bool 223 224config 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 244config 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 252config 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 260config 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 268config 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 278config 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 285source "drivers/md/persistent-data/Kconfig" 286 287config 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 294config 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 318config 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 329config 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 336config 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 344config 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 357config 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 369config 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 380config 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 388config 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 399config 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 413config 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 420config 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 431config 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 459config 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 466config 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 477config 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 486config 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 496config 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 507config 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 516config 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 525config 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 534config 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 546config DM_UEVENT 547 bool "DM uevents" 548 depends on BLK_DEV_DM 549 help 550 Generate udev events for DM events. 551 552config 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 558config 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 581config 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 594config 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 603config 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 613config 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 623config 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 637config 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 653config 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 674config 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 694config 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 704source "drivers/md/dm-vdo/Kconfig" 705 706source "drivers/md/dm-pcache/Kconfig" 707 708endif # MD 709