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