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