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