drivers/md/Kconfig

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