| 1 | # |
| 2 | # Block device driver configuration |
| 3 | # |
| 4 | |
| 5 | menuconfig MD |
| 6 | bool "Multiple devices driver support (RAID and LVM)" |
| 7 | depends on BLOCK |
| 8 | help |
| 9 | Support multiple physical spindles through a single logical device. |
| 10 | Required for RAID and logical volume management. |
| 11 | |
| 12 | if MD |
| 13 | |
| 14 | config BLK_DEV_MD |
| 15 | tristate "RAID support" |
| 16 | ---help--- |
| 17 | This driver lets you combine several hard disk partitions into one |
| 18 | logical block device. This can be used to simply append one |
| 19 | partition to another one or to combine several redundant hard disks |
| 20 | into a RAID1/4/5 device so as to provide protection against hard |
| 21 | disk failures. This is called "Software RAID" since the combining of |
| 22 | the partitions is done by the kernel. "Hardware RAID" means that the |
| 23 | combining is done by a dedicated controller; if you have such a |
| 24 | controller, you do not need to say Y here. |
| 25 | |
| 26 | More information about Software RAID on Linux is contained in the |
| 27 | Software RAID mini-HOWTO, available from |
| 28 | <http://www.tldp.org/docs.html#howto>. There you will also learn |
| 29 | where to get the supporting user space utilities raidtools. |
| 30 | |
| 31 | If unsure, say N. |
| 32 | |
| 33 | config MD_AUTODETECT |
| 34 | bool "Autodetect RAID arrays during kernel boot" |
| 35 | depends on BLK_DEV_MD=y |
| 36 | default y |
| 37 | ---help--- |
| 38 | If you say Y here, then the kernel will try to autodetect raid |
| 39 | arrays as part of its boot process. |
| 40 | |
| 41 | If you don't use raid and say Y, this autodetection can cause |
| 42 | a several-second delay in the boot time due to various |
| 43 | synchronisation steps that are part of this step. |
| 44 | |
| 45 | If unsure, say Y. |
| 46 | |
| 47 | config MD_LINEAR |
| 48 | tristate "Linear (append) mode" |
| 49 | depends on BLK_DEV_MD |
| 50 | ---help--- |
| 51 | If you say Y here, then your multiple devices driver will be able to |
| 52 | use the so-called linear mode, i.e. it will combine the hard disk |
| 53 | partitions by simply appending one to the other. |
| 54 | |
| 55 | To compile this as a module, choose M here: the module |
| 56 | will be called linear. |
| 57 | |
| 58 | If unsure, say Y. |
| 59 | |
| 60 | config MD_RAID0 |
| 61 | tristate "RAID-0 (striping) mode" |
| 62 | depends on BLK_DEV_MD |
| 63 | ---help--- |
| 64 | If you say Y here, then your multiple devices driver will be able to |
| 65 | use the so-called raid0 mode, i.e. it will combine the hard disk |
| 66 | partitions into one logical device in such a fashion as to fill them |
| 67 | up evenly, one chunk here and one chunk there. This will increase |
| 68 | the throughput rate if the partitions reside on distinct disks. |
| 69 | |
| 70 | Information about Software RAID on Linux is contained in the |
| 71 | Software-RAID mini-HOWTO, available from |
| 72 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 73 | learn where to get the supporting user space utilities raidtools. |
| 74 | |
| 75 | To compile this as a module, choose M here: the module |
| 76 | will be called raid0. |
| 77 | |
| 78 | If unsure, say Y. |
| 79 | |
| 80 | config MD_RAID1 |
| 81 | tristate "RAID-1 (mirroring) mode" |
| 82 | depends on BLK_DEV_MD |
| 83 | ---help--- |
| 84 | A RAID-1 set consists of several disk drives which are exact copies |
| 85 | of each other. In the event of a mirror failure, the RAID driver |
| 86 | will continue to use the operational mirrors in the set, providing |
| 87 | an error free MD (multiple device) to the higher levels of the |
| 88 | kernel. In a set with N drives, the available space is the capacity |
| 89 | of a single drive, and the set protects against a failure of (N - 1) |
| 90 | drives. |
| 91 | |
| 92 | Information about Software RAID on Linux is contained in the |
| 93 | Software-RAID mini-HOWTO, available from |
| 94 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 95 | learn where to get the supporting user space utilities raidtools. |
| 96 | |
| 97 | If you want to use such a RAID-1 set, say Y. To compile this code |
| 98 | as a module, choose M here: the module will be called raid1. |
| 99 | |
| 100 | If unsure, say Y. |
| 101 | |
| 102 | config MD_RAID10 |
| 103 | tristate "RAID-10 (mirrored striping) mode" |
| 104 | depends on BLK_DEV_MD |
| 105 | ---help--- |
| 106 | RAID-10 provides a combination of striping (RAID-0) and |
| 107 | mirroring (RAID-1) with easier configuration and more flexible |
| 108 | layout. |
| 109 | Unlike RAID-0, but like RAID-1, RAID-10 requires all devices to |
| 110 | be the same size (or at least, only as much as the smallest device |
| 111 | will be used). |
| 112 | RAID-10 provides a variety of layouts that provide different levels |
| 113 | of redundancy and performance. |
| 114 | |
| 115 | RAID-10 requires mdadm-1.7.0 or later, available at: |
| 116 | |
| 117 | ftp://ftp.kernel.org/pub/linux/utils/raid/mdadm/ |
| 118 | |
| 119 | If unsure, say Y. |
| 120 | |
| 121 | config MD_RAID456 |
| 122 | tristate "RAID-4/RAID-5/RAID-6 mode" |
| 123 | depends on BLK_DEV_MD |
| 124 | select RAID6_PQ |
| 125 | select ASYNC_MEMCPY |
| 126 | select ASYNC_XOR |
| 127 | select ASYNC_PQ |
| 128 | select ASYNC_RAID6_RECOV |
| 129 | ---help--- |
| 130 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 131 | the capacity of C * (N - 1) MB, and protects against a failure |
| 132 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 133 | contain data sectors, and one drive contains the parity protection. |
| 134 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 135 | while a RAID-5 set distributes the parity across the drives in one |
| 136 | of the available parity distribution methods. |
| 137 | |
| 138 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 139 | provides the capacity of C * (N - 2) MB, and protects |
| 140 | against a failure of any two drives. For a given sector |
| 141 | (row) number, (N - 2) drives contain data sectors, and two |
| 142 | drives contains two independent redundancy syndromes. Like |
| 143 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 144 | in one of the available parity distribution methods. |
| 145 | |
| 146 | Information about Software RAID on Linux is contained in the |
| 147 | Software-RAID mini-HOWTO, available from |
| 148 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 149 | learn where to get the supporting user space utilities raidtools. |
| 150 | |
| 151 | If you want to use such a RAID-4/RAID-5/RAID-6 set, say Y. To |
| 152 | compile this code as a module, choose M here: the module |
| 153 | will be called raid456. |
| 154 | |
| 155 | If unsure, say Y. |
| 156 | |
| 157 | config MD_MULTIPATH |
| 158 | tristate "Multipath I/O support" |
| 159 | depends on BLK_DEV_MD |
| 160 | help |
| 161 | MD_MULTIPATH provides a simple multi-path personality for use |
| 162 | the MD framework. It is not under active development. New |
| 163 | projects should consider using DM_MULTIPATH which has more |
| 164 | features and more testing. |
| 165 | |
| 166 | If unsure, say N. |
| 167 | |
| 168 | config MD_FAULTY |
| 169 | tristate "Faulty test module for MD" |
| 170 | depends on BLK_DEV_MD |
| 171 | help |
| 172 | The "faulty" module allows for a block device that occasionally returns |
| 173 | read or write errors. It is useful for testing. |
| 174 | |
| 175 | In unsure, say N. |
| 176 | |
| 177 | source "drivers/md/bcache/Kconfig" |
| 178 | |
| 179 | config BLK_DEV_DM_BUILTIN |
| 180 | boolean |
| 181 | |
| 182 | config BLK_DEV_DM |
| 183 | tristate "Device mapper support" |
| 184 | select BLK_DEV_DM_BUILTIN |
| 185 | ---help--- |
| 186 | Device-mapper is a low level volume manager. It works by allowing |
| 187 | people to specify mappings for ranges of logical sectors. Various |
| 188 | mapping types are available, in addition people may write their own |
| 189 | modules containing custom mappings if they wish. |
| 190 | |
| 191 | Higher level volume managers such as LVM2 use this driver. |
| 192 | |
| 193 | To compile this as a module, choose M here: the module will be |
| 194 | called dm-mod. |
| 195 | |
| 196 | If unsure, say N. |
| 197 | |
| 198 | config DM_DEBUG |
| 199 | boolean "Device mapper debugging support" |
| 200 | depends on BLK_DEV_DM |
| 201 | ---help--- |
| 202 | Enable this for messages that may help debug device-mapper problems. |
| 203 | |
| 204 | If unsure, say N. |
| 205 | |
| 206 | config DM_BUFIO |
| 207 | tristate |
| 208 | depends on BLK_DEV_DM |
| 209 | ---help--- |
| 210 | This interface allows you to do buffered I/O on a device and acts |
| 211 | as a cache, holding recently-read blocks in memory and performing |
| 212 | delayed writes. |
| 213 | |
| 214 | config DM_BIO_PRISON |
| 215 | tristate |
| 216 | depends on BLK_DEV_DM |
| 217 | ---help--- |
| 218 | Some bio locking schemes used by other device-mapper targets |
| 219 | including thin provisioning. |
| 220 | |
| 221 | source "drivers/md/persistent-data/Kconfig" |
| 222 | |
| 223 | config DM_CRYPT |
| 224 | tristate "Crypt target support" |
| 225 | depends on BLK_DEV_DM |
| 226 | select CRYPTO |
| 227 | select CRYPTO_CBC |
| 228 | ---help--- |
| 229 | This device-mapper target allows you to create a device that |
| 230 | transparently encrypts the data on it. You'll need to activate |
| 231 | the ciphers you're going to use in the cryptoapi configuration. |
| 232 | |
| 233 | Information on how to use dm-crypt can be found on |
| 234 | |
| 235 | <http://www.saout.de/misc/dm-crypt/> |
| 236 | |
| 237 | To compile this code as a module, choose M here: the module will |
| 238 | be called dm-crypt. |
| 239 | |
| 240 | If unsure, say N. |
| 241 | |
| 242 | config DM_SNAPSHOT |
| 243 | tristate "Snapshot target" |
| 244 | depends on BLK_DEV_DM |
| 245 | select DM_BUFIO |
| 246 | ---help--- |
| 247 | Allow volume managers to take writable snapshots of a device. |
| 248 | |
| 249 | config DM_THIN_PROVISIONING |
| 250 | tristate "Thin provisioning target" |
| 251 | depends on BLK_DEV_DM |
| 252 | select DM_PERSISTENT_DATA |
| 253 | select DM_BIO_PRISON |
| 254 | ---help--- |
| 255 | Provides thin provisioning and snapshots that share a data store. |
| 256 | |
| 257 | config DM_CACHE |
| 258 | tristate "Cache target (EXPERIMENTAL)" |
| 259 | depends on BLK_DEV_DM |
| 260 | default n |
| 261 | select DM_PERSISTENT_DATA |
| 262 | select DM_BIO_PRISON |
| 263 | ---help--- |
| 264 | dm-cache attempts to improve performance of a block device by |
| 265 | moving frequently used data to a smaller, higher performance |
| 266 | device. Different 'policy' plugins can be used to change the |
| 267 | algorithms used to select which blocks are promoted, demoted, |
| 268 | cleaned etc. It supports writeback and writethrough modes. |
| 269 | |
| 270 | config DM_CACHE_MQ |
| 271 | tristate "MQ Cache Policy (EXPERIMENTAL)" |
| 272 | depends on DM_CACHE |
| 273 | default y |
| 274 | ---help--- |
| 275 | A cache policy that uses a multiqueue ordered by recent hit |
| 276 | count to select which blocks should be promoted and demoted. |
| 277 | This is meant to be a general purpose policy. It prioritises |
| 278 | reads over writes. |
| 279 | |
| 280 | config DM_CACHE_CLEANER |
| 281 | tristate "Cleaner Cache Policy (EXPERIMENTAL)" |
| 282 | depends on DM_CACHE |
| 283 | default y |
| 284 | ---help--- |
| 285 | A simple cache policy that writes back all data to the |
| 286 | origin. Used when decommissioning a dm-cache. |
| 287 | |
| 288 | config DM_ERA |
| 289 | tristate "Era target (EXPERIMENTAL)" |
| 290 | depends on BLK_DEV_DM |
| 291 | default n |
| 292 | select DM_PERSISTENT_DATA |
| 293 | select DM_BIO_PRISON |
| 294 | ---help--- |
| 295 | dm-era tracks which parts of a block device are written to |
| 296 | over time. Useful for maintaining cache coherency when using |
| 297 | vendor snapshots. |
| 298 | |
| 299 | config DM_MIRROR |
| 300 | tristate "Mirror target" |
| 301 | depends on BLK_DEV_DM |
| 302 | ---help--- |
| 303 | Allow volume managers to mirror logical volumes, also |
| 304 | needed for live data migration tools such as 'pvmove'. |
| 305 | |
| 306 | config DM_LOG_USERSPACE |
| 307 | tristate "Mirror userspace logging" |
| 308 | depends on DM_MIRROR && NET |
| 309 | select CONNECTOR |
| 310 | ---help--- |
| 311 | The userspace logging module provides a mechanism for |
| 312 | relaying the dm-dirty-log API to userspace. Log designs |
| 313 | which are more suited to userspace implementation (e.g. |
| 314 | shared storage logs) or experimental logs can be implemented |
| 315 | by leveraging this framework. |
| 316 | |
| 317 | config DM_RAID |
| 318 | tristate "RAID 1/4/5/6/10 target" |
| 319 | depends on BLK_DEV_DM |
| 320 | select MD_RAID1 |
| 321 | select MD_RAID10 |
| 322 | select MD_RAID456 |
| 323 | select BLK_DEV_MD |
| 324 | ---help--- |
| 325 | A dm target that supports RAID1, RAID10, RAID4, RAID5 and RAID6 mappings |
| 326 | |
| 327 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 328 | the capacity of C * (N - 1) MB, and protects against a failure |
| 329 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 330 | contain data sectors, and one drive contains the parity protection. |
| 331 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 332 | while a RAID-5 set distributes the parity across the drives in one |
| 333 | of the available parity distribution methods. |
| 334 | |
| 335 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 336 | provides the capacity of C * (N - 2) MB, and protects |
| 337 | against a failure of any two drives. For a given sector |
| 338 | (row) number, (N - 2) drives contain data sectors, and two |
| 339 | drives contains two independent redundancy syndromes. Like |
| 340 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 341 | in one of the available parity distribution methods. |
| 342 | |
| 343 | config DM_ZERO |
| 344 | tristate "Zero target" |
| 345 | depends on BLK_DEV_DM |
| 346 | ---help--- |
| 347 | A target that discards writes, and returns all zeroes for |
| 348 | reads. Useful in some recovery situations. |
| 349 | |
| 350 | config DM_MULTIPATH |
| 351 | tristate "Multipath target" |
| 352 | depends on BLK_DEV_DM |
| 353 | # nasty syntax but means make DM_MULTIPATH independent |
| 354 | # of SCSI_DH if the latter isn't defined but if |
| 355 | # it is, DM_MULTIPATH must depend on it. We get a build |
| 356 | # error if SCSI_DH=m and DM_MULTIPATH=y |
| 357 | depends on SCSI_DH || !SCSI_DH |
| 358 | ---help--- |
| 359 | Allow volume managers to support multipath hardware. |
| 360 | |
| 361 | config DM_MULTIPATH_QL |
| 362 | tristate "I/O Path Selector based on the number of in-flight I/Os" |
| 363 | depends on DM_MULTIPATH |
| 364 | ---help--- |
| 365 | This path selector is a dynamic load balancer which selects |
| 366 | the path with the least number of in-flight I/Os. |
| 367 | |
| 368 | If unsure, say N. |
| 369 | |
| 370 | config DM_MULTIPATH_ST |
| 371 | tristate "I/O Path Selector based on the service time" |
| 372 | depends on DM_MULTIPATH |
| 373 | ---help--- |
| 374 | This path selector is a dynamic load balancer which selects |
| 375 | the path expected to complete the incoming I/O in the shortest |
| 376 | time. |
| 377 | |
| 378 | If unsure, say N. |
| 379 | |
| 380 | config DM_DELAY |
| 381 | tristate "I/O delaying target" |
| 382 | depends on BLK_DEV_DM |
| 383 | ---help--- |
| 384 | A target that delays reads and/or writes and can send |
| 385 | them to different devices. Useful for testing. |
| 386 | |
| 387 | If unsure, say N. |
| 388 | |
| 389 | config DM_UEVENT |
| 390 | bool "DM uevents" |
| 391 | depends on BLK_DEV_DM |
| 392 | ---help--- |
| 393 | Generate udev events for DM events. |
| 394 | |
| 395 | config DM_FLAKEY |
| 396 | tristate "Flakey target" |
| 397 | depends on BLK_DEV_DM |
| 398 | ---help--- |
| 399 | A target that intermittently fails I/O for debugging purposes. |
| 400 | |
| 401 | config DM_VERITY |
| 402 | tristate "Verity target support" |
| 403 | depends on BLK_DEV_DM |
| 404 | select CRYPTO |
| 405 | select CRYPTO_HASH |
| 406 | select DM_BUFIO |
| 407 | ---help--- |
| 408 | This device-mapper target creates a read-only device that |
| 409 | transparently validates the data on one underlying device against |
| 410 | a pre-generated tree of cryptographic checksums stored on a second |
| 411 | device. |
| 412 | |
| 413 | You'll need to activate the digests you're going to use in the |
| 414 | cryptoapi configuration. |
| 415 | |
| 416 | To compile this code as a module, choose M here: the module will |
| 417 | be called dm-verity. |
| 418 | |
| 419 | If unsure, say N. |
| 420 | |
| 421 | config DM_SWITCH |
| 422 | tristate "Switch target support (EXPERIMENTAL)" |
| 423 | depends on BLK_DEV_DM |
| 424 | ---help--- |
| 425 | This device-mapper target creates a device that supports an arbitrary |
| 426 | mapping of fixed-size regions of I/O across a fixed set of paths. |
| 427 | The path used for any specific region can be switched dynamically |
| 428 | by sending the target a message. |
| 429 | |
| 430 | To compile this code as a module, choose M here: the module will |
| 431 | be called dm-switch. |
| 432 | |
| 433 | If unsure, say N. |
| 434 | |
| 435 | endif # MD |