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