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