{
    "content": [
        {
            "type": "text",
            "text": "# md(4) (man)\n\n**Summary:** md - Multiple Device driver aka Linux Software RAID\n\n**Synopsis:** /dev/mdn\n/dev/md/n\n/dev/md/name\n\n## See Also\n\n- mdadm(8)\n- MD(4)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **SYNOPSIS** (4 lines)\n- **DESCRIPTION** (217 lines) — 12 subsections\n  - About the RAID10 Layout Examples: (16 lines)\n  - \"near\" Layout (41 lines)\n  - \"far\" Layout (66 lines)\n  - \"offset\" Layout (451 lines)\n  - md/bitmap/backlog (21 lines)\n  - md/bitmap/chunksize (4 lines)\n  - md/bitmap/location (14 lines)\n  - md/bitmap/metadata (6 lines)\n  - md/bitmap/space (18 lines)\n  - raid=noautodetect (7 lines)\n  - raid=partitionable (1 lines)\n  - raid=part (44 lines)\n- **FILES** (1 lines) — 1 subsections\n  - /proc/mdstat (14 lines)\n- **SEE ALSO** (5 lines)\n\n## Full Content\n\n### NAME\n\nmd - Multiple Device driver aka Linux Software RAID\n\n### SYNOPSIS\n\n/dev/mdn\n/dev/md/n\n/dev/md/name\n\n### DESCRIPTION\n\nThe md driver provides virtual devices that are created from one or more independent underly‐\ning devices.  This array of devices often contains redundancy and the devices are often  disk\ndrives, hence the acronym RAID which stands for a Redundant Array of Independent Disks.\n\nmd supports RAID levels 1 (mirroring), 4 (striped array with parity device), 5 (striped array\nwith distributed parity information), 6 (striped array with distributed dual  redundancy  in‐\nformation),  and 10 (striped and mirrored).  If some number of underlying devices fails while\nusing one of these levels, the array will continue to function; this number is one  for  RAID\nlevels  4  and 5, two for RAID level 6, and all but one (N-1) for RAID level 1, and dependent\non configuration for level 10.\n\nmd also supports a number of  pseudo  RAID  (non-redundant)  configurations  including  RAID0\n(striped  array),  LINEAR  (catenated array), MULTIPATH (a set of different interfaces to the\nsame device), and FAULTY (a layer over a single device into which errors can be injected).\n\n\nMD METADATA\nEach device in an array may have some metadata stored in the device.  This metadata is  some‐\ntimes called a superblock.  The metadata records information about the structure and state of\nthe array.  This allows the array to be reliably re-assembled after a shutdown.\n\nFrom Linux kernel version 2.6.10, md provides support for two different formats of  metadata,\nand other formats can be added.  Prior to this release, only one format is supported.\n\nThe  common  format — known as version 0.90 — has a superblock that is 4K long and is written\ninto a 64K aligned block that starts at least 64K and less than 128K from the end of the  de‐\nvice (i.e. to get the address of the superblock round the size of the device down to a multi‐\nple of 64K and then subtract 64K).  The available size of each device is the amount of  space\nbefore the super block, so between 64K and 128K is lost when a device in incorporated into an\nMD array.  This superblock stores multi-byte fields in a processor-dependent manner,  so  ar‐\nrays cannot easily be moved between computers with different processors.\n\nThe  new  format — known as version 1 — has a superblock that is normally 1K long, but can be\nlonger.  It is normally stored between 8K and 12K from the end of the device, on a 4K  bound‐\nary,  though variations can be stored at the start of the device (version 1.1) or 4K from the\nstart of the device (version 1.2).  This metadata format stores multibyte data in  a  proces‐\nsor-independent  format  and  supports up to hundreds of component devices (version 0.90 only\nsupports 28).\n\nThe metadata contains, among other things:\n\nLEVEL  The manner in which the devices are arranged into the  array  (LINEAR,  RAID0,  RAID1,\nRAID4, RAID5, RAID10, MULTIPATH).\n\nUUID   a  128  bit Universally Unique Identifier that identifies the array that contains this\ndevice.\n\n\nWhen a version 0.90 array is being reshaped (e.g. adding extra devices to a RAID5), the  ver‐\nsion  number is temporarily set to 0.91.  This ensures that if the reshape process is stopped\nin the middle (e.g. by a system crash) and the machine boots into an older kernel  that  does\nnot  support  reshaping, then the array will not be assembled (which would cause data corrup‐\ntion) but will be left untouched until a kernel that can complete the  reshape  processes  is\nused.\n\n\nARRAYS WITHOUT METADATA\nWhile  it is usually best to create arrays with superblocks so that they can be assembled re‐\nliably, there are some circumstances when an array without superblocks is  preferred.   These\ninclude:\n\nLEGACY ARRAYS\nEarly versions of the md driver only supported LINEAR and RAID0 configurations and did\nnot use a superblock (which is less critical with these configurations).   While  such\narrays should be rebuilt with superblocks if possible, md continues to support them.\n\nFAULTY Being  a  largely  transparent  layer  over a different device, the FAULTY personality\ndoesn't gain anything from having a superblock.\n\nMULTIPATH\nIt is often possible to detect devices which are different paths to the  same  storage\ndirectly  rather  than  having  a  distinctive  superblock  written  to the device and\nsearched for on all paths.  In this case, a MULTIPATH array with no  superblock  makes\nsense.\n\nRAID1  In  some  configurations it might be desired to create a RAID1 configuration that does\nnot use a superblock, and to maintain the state of the array elsewhere.  While not en‐\ncouraged for general use, it does have special-purpose uses and is supported.\n\n\nARRAYS WITH EXTERNAL METADATA\nFrom  release  2.6.28,  the md driver supports arrays with externally managed metadata.  That\nis, the metadata is not managed by the kernel but rather by a user-space program which is ex‐\nternal to the kernel.  This allows support for a variety of metadata formats without clutter‐\ning the kernel with lots of details.\n\nmd is able to communicate with the user-space program through  various  sysfs  attributes  so\nthat  it  can  make  appropriate  changes  to  the metadata - for example to mark a device as\nfaulty.  When necessary, md will wait for the program to acknowledge the event by writing  to\na sysfs attribute.  The manual page for mdmon(8) contains more detail about this interaction.\n\n\nCONTAINERS\nMany metadata formats use a single block of metadata to describe a number of different arrays\nwhich all use the same set of devices.  In this case it is helpful for  the  kernel  to  know\nabout  the  full  set of devices as a whole.  This set is known to md as a container.  A con‐\ntainer is an md array with externally managed metadata and with device  offset  and  size  so\nthat it just covers the metadata part of the devices.  The remainder of each device is avail‐\nable to be incorporated into various arrays.\n\n\nLINEAR\nA LINEAR array simply catenates the available space on each drive to form one  large  virtual\ndrive.\n\nOne  advantage  of  this arrangement over the more common RAID0 arrangement is that the array\nmay be reconfigured at a later time with an extra drive, so the array is made bigger  without\ndisturbing the data that is on the array.  This can even be done on a live array.\n\nIf  a chunksize is given with a LINEAR array, the usable space on each device is rounded down\nto a multiple of this chunksize.\n\n\nRAID0\nA RAID0 array (which has zero redundancy) is also known as a striped array.  A RAID0 array is\nconfigured  at  creation  with  a  Chunk  Size  which  must be a power of two (prior to Linux\n2.6.31), and at least 4 kibibytes.\n\nThe RAID0 driver assigns the first chunk of the array to the first device, the  second  chunk\nto  the second device, and so on until all drives have been assigned one chunk.  This collec‐\ntion of chunks forms a stripe.  Further chunks are gathered into stripes in the same way, and\nare assigned to the remaining space in the drives.\n\nIf devices in the array are not all the same size, then once the smallest device has been ex‐\nhausted, the RAID0 driver starts collecting chunks into smaller stripes that  only  span  the\ndrives which still have remaining space.\n\nA  bug  was introduced in linux 3.14 which changed the layout of blocks in a RAID0 beyond the\nregion that is striped over all devices.  This bug does not affect an array with all  devices\nthe same size, but can affect other RAID0 arrays.\n\nLinux  5.4 (and some stable kernels to which the change was backported) will not normally as‐\nsemble such an array as it cannot know which layout to use.   There  is  a  module  parameter\n\"raid0.defaultlayout\" which can be set to \"1\" to force the kernel to use the pre-3.14 layout\nor to \"2\" to force it to use the 3.14-and-later layout.  when creating  a  new  RAID0  array,\nmdadm will record the chosen layout in the metadata in a way that allows newer kernels to as‐\nsemble the array without needing a module parameter.\n\nTo assemble an old array on a new kernel without using the module parameter, use  either  the\n--update=layout-original option or the --update=layout-alternate option.\n\nOnce  you have updated the layout you will not be able to mount the array on an older kernel.\nIf you need to revert to an older kernel, the layout information can be erased with the --up‐‐\ndate=layout-unspecificed  option.  If you use this option to --assemble while running a newer\nkernel, the array will NOT assemble, but the metadata will be update so that it can be assem‐\nbled on an older kernel.\n\nNo  that  setting  the  layout to \"unspecified\" removes protections against this bug, and you\nmust be sure that the kernel you use matches the layout of the array.\n\n\nRAID1\nA RAID1 array is also known as a mirrored set (though mirrors tend to provide  reflected  im‐\nages, which RAID1 does not) or a plex.\n\nOnce  initialised,  each device in a RAID1 array contains exactly the same data.  Changes are\nwritten to all devices in parallel.  Data is read from any one device.  The  driver  attempts\nto distribute read requests across all devices to maximise performance.\n\nAll  devices in a RAID1 array should be the same size.  If they are not, then only the amount\nof space available on the smallest device is used  (any  extra  space  on  other  devices  is\nwasted).\n\nNote  that  the read balancing done by the driver does not make the RAID1 performance profile\nbe the same as for RAID0; a single stream of sequential input will not be accelerated (e.g. a\nsingle dd), but multiple sequential streams or a random workload will use more than one spin‐\ndle. In theory, having an N-disk RAID1 will allow N  sequential  threads  to  read  from  all\ndisks.\n\nIndividual  devices  in  a  RAID1 can be marked as \"write-mostly\".  These drives are excluded\nfrom the normal read balancing and will only be read from when  there  is  no  other  option.\nThis can be useful for devices connected over a slow link.\n\n\nRAID4\nA  RAID4  array is like a RAID0 array with an extra device for storing parity. This device is\nthe last of the active devices in the array. Unlike  RAID0,  RAID4  also  requires  that  all\nstripes  span  all  drives,  so  extra  space on devices that are larger than the smallest is\nwasted.\n\nWhen any block in a RAID4 array is modified, the parity block for that stripe (i.e. the block\nin  the  parity  device at the same device offset as the stripe) is also modified so that the\nparity block always contains the \"parity\" for the whole stripe.  I.e. its content is  equiva‐\nlent to the result of performing an exclusive-or operation between all the data blocks in the\nstripe.\n\nThis allows the array to continue to function if one device fails.  The data that was on that\ndevice can be calculated as needed from the parity block and the other data blocks.\n\n\nRAID5\nRAID5  is  very  similar to RAID4.  The difference is that the parity blocks for each stripe,\ninstead of being on a single device, are distributed across all devices.   This  allows  more\nparallelism  when  writing,  as two different block updates will quite possibly affect parity\nblocks on different devices so there is less contention.\n\nThis also allows more parallelism when reading, as read requests are distributed over all the\ndevices in the array instead of all but one.\n\n\nRAID6\nRAID6 is similar to RAID5, but can handle the loss of any two devices without data loss.  Ac‐\ncordingly, it requires N+2 drives to store N drives worth of data.\n\nThe performance for RAID6 is slightly lower but comparable to RAID5 in normal mode and single\ndisk failure mode.  It is very slow in dual disk failure mode, however.\n\n\nRAID10\nRAID10  provides  a combination of RAID1 and RAID0, and is sometimes known as RAID1+0.  Every\ndatablock is duplicated some number of times, and the resulting collection of datablocks  are\ndistributed over multiple drives.\n\nWhen  configuring  a  RAID10 array, it is necessary to specify the number of replicas of each\ndata block that are required (this will usually be 2) and  whether  their  layout  should  be\n\"near\", \"far\" or \"offset\" (with \"offset\" being available since Linux 2.6.18).\n\n#### About the RAID10 Layout Examples:\n\nThe examples below visualise the chunk distribution on the underlying devices for the respec‐\ntive layout.\n\nFor simplicity it is assumed that the size of the chunks equals the size of the blocks of the\nunderlying  devices as well as those of the RAID10 device exported by the kernel (for example\n/dev/md/name).\nTherefore the chunks / chunk numbers map directly to the blocks /block addresses of  the  ex‐\nported RAID10 device.\n\nDecimal  numbers  (0, 1, 2, ...) are the chunks of the RAID10 and due to the above assumption\nalso the blocks and block addresses of the exported RAID10 device.\nRepeated numbers mean copies of a chunk / block (obviously on different underlying devices).\nHexadecimal numbers (0x00, 0x01, 0x02, ...) are the block addresses  of  the  underlying  de‐\nvices.\n\n#### \"near\" Layout\n\nWhen  \"near\"  replicas  are  chosen, the multiple copies of a given chunk are laid out\nconsecutively (\"as close to each other as possible\") across the stripes of the array.\n\nWith an even number of devices, they will likely (unless some misalignment is present)\nlay at the very same offset on the different devices.\nThis is as the \"classic\" RAID1+0; that is two groups of mirrored devices (in the exam‐\nple below the groups Device #1 / #2 and Device #3 / #4 are each a RAID1) both in  turn\nforming a striped RAID0.\n\nExample with 2 copies per chunk and an even number (4) of devices:\n\n┌───────────┌───────────┌───────────┌───────────┐\n│ Device #1 │ Device #2 │ Device #3 │ Device #4 │\n┌─────├───────────├───────────├───────────├───────────┤\n│0x00 │     0     │     0     │     1     │     1     │\n│0x01 │     2     │     2     │     3     │     3     │\n│     │    ...    │    ...    │    ...    │    ...    │\n│ :   │     :     │     :     │     :     │     :     │\n│     │    ...    │    ...    │    ...    │    ...    │\n│0x80 │    254    │    254    │    255    │    255    │\n└─────└───────────└───────────└───────────└───────────┘\n\\---------v---------/   \\---------v---------/\nRAID1                   RAID1\n\\---------------------v---------------------/\nRAID0\n\nExample with 2 copies per chunk and an odd number (5) of devices:\n\n┌────────┌────────┌────────┌────────┌────────┐\n│ Dev #1 │ Dev #2 │ Dev #3 │ Dev #4 │ Dev #5 │\n┌─────├────────├────────├────────├────────├────────┤\n│0x00 │   0    │   0    │   1    │   1    │   2    │\n│0x01 │   2    │   3    │   3    │   4    │   4    │\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │\n│ :   │   :    │   :    │   :    │   :    │   :    │\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │\n│0x80 │  317   │  318   │  318   │  319   │  319   │\n└─────└────────└────────└────────└────────└────────┘\n\n#### \"far\" Layout\n\nWhen  \"far\"  replicas  are  chosen,  the multiple copies of a given chunk are laid out\nquite distant (\"as far as reasonably possible\") from each other.\n\nFirst a complete sequence of all data blocks (that is all the data one sees on the ex‐\nported  RAID10  block  device)  is  striped  over  the  devices.  Then another (though\n\"shifted\") complete sequence of all data blocks; and so on (in the case of  more  than\n2 copies per chunk).\n\nThe \"shift\" needed to prevent placing copies of the same chunks on the same devices is\nactually a cyclic permutation with offset 1 of each of the stripes within  a  complete\nsequence of chunks.\nThe  offset 1  is  relative to the previous complete sequence of chunks, so in case of\nmore than 2 copies per chunk one gets the following offsets:\n1. complete sequence of chunks: offset =  0\n2. complete sequence of chunks: offset =  1\n3. complete sequence of chunks: offset =  2\n:\nn. complete sequence of chunks: offset = n-1\n\nExample with 2 copies per chunk and an even number (4) of devices:\n\n┌───────────┌───────────┌───────────┌───────────┐\n│ Device #1 │ Device #2 │ Device #3 │ Device #4 │\n┌─────├───────────├───────────├───────────├───────────┤\n│0x00 │     0     │     1     │     2     │     3     │ \\\n│0x01 │     4     │     5     │     6     │     7     │ > [#]\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│ :   │     :     │     :     │     :     │     :     │ :\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│0x40 │    252    │    253    │    254    │    255    │ /\n│0x41 │     3     │     0     │     1     │     2     │ \\\n│0x42 │     7     │     4     │     5     │     6     │ > [#]~\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│ :   │     :     │     :     │     :     │     :     │ :\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│0x80 │    255    │    252    │    253    │    254    │ /\n└─────└───────────└───────────└───────────└───────────┘\n\nExample with 2 copies per chunk and an odd number (5) of devices:\n\n┌────────┌────────┌────────┌────────┌────────┐\n│ Dev #1 │ Dev #2 │ Dev #3 │ Dev #4 │ Dev #5 │\n┌─────├────────├────────├────────├────────├────────┤\n│0x00 │   0    │   1    │   2    │   3    │   4    │ \\\n│0x01 │   5    │   6    │   7    │   8    │   9    │ > [#]\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│ :   │   :    │   :    │   :    │   :    │   :    │ :\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│0x40 │  315   │  316   │  317   │  318   │  319   │ /\n│0x41 │   4    │   0    │   1    │   2    │   3    │ \\\n│0x42 │   9    │   5    │   6    │   7    │   8    │ > [#]~\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│ :   │   :    │   :    │   :    │   :    │   :    │ :\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│0x80 │  319   │  315   │  316   │  317   │  318   │ /\n└─────└────────└────────└────────└────────└────────┘\n\nWith [#] being the complete sequence of chunks and [#]~ the  cyclic  permutation  with\noffset 1  thereof  (in  the  case  of  more  than  2  copies  per chunk there would be\n([#]~)~, (([#]~)~)~, ...).\n\nThe advantage of this layout is that MD can easily spread sequential  reads  over  the\ndevices, making them similar to RAID0 in terms of speed.\nThe cost is more seeking for writes, making them substantially slower.\n\n#### \"offset\" Layout\n\nWhen \"offset\" replicas are chosen, all the copies of a given chunk are striped consec‐\nutively (\"offset by the stripe length after each other\") over the devices.\n\nExplained in detail, <number of devices> consecutive chunks are striped over  the  de‐\nvices,  immediately  followed by a \"shifted\" copy of these chunks (and by further such\n\"shifted\" copies in the case of more than 2 copies per chunk).\nThis pattern repeats for all further consecutive chunks of the exported RAID10  device\n(in other words: all further data blocks).\n\nThe \"shift\" needed to prevent placing copies of the same chunks on the same devices is\nactually a cyclic permutation with offset 1 of each of the striped copies  of  <number\nof devices> consecutive chunks.\nThe  offset 1 is relative to the previous striped copy of <number of devices> consecu‐\ntive chunks, so in case of more than 2 copies per chunk one gets  the  following  off‐\nsets:\n1. <number of devices> consecutive chunks: offset =  0\n2. <number of devices> consecutive chunks: offset =  1\n3. <number of devices> consecutive chunks: offset =  2\n:\nn. <number of devices> consecutive chunks: offset = n-1\n\nExample with 2 copies per chunk and an even number (4) of devices:\n\n┌───────────┌───────────┌───────────┌───────────┐\n│ Device #1 │ Device #2 │ Device #3 │ Device #4 │\n┌─────├───────────├───────────├───────────├───────────┤\n│0x00 │     0     │     1     │     2     │     3     │ ) AA\n│0x01 │     3     │     0     │     1     │     2     │ ) AA~\n│0x02 │     4     │     5     │     6     │     7     │ ) AB\n│0x03 │     7     │     4     │     5     │     6     │ ) AB~\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│ :   │     :     │     :     │     :     │     :     │   :\n│     │    ...    │    ...    │    ...    │    ...    │ ...\n│0x79 │    251    │    252    │    253    │    254    │ ) EX\n│0x80 │    254    │    251    │    252    │    253    │ ) EX~\n└─────└───────────└───────────└───────────└───────────┘\n\nExample with 2 copies per chunk and an odd number (5) of devices:\n\n┌────────┌────────┌────────┌────────┌────────┐\n│ Dev #1 │ Dev #2 │ Dev #3 │ Dev #4 │ Dev #5 │\n┌─────├────────├────────├────────├────────├────────┤\n│0x00 │   0    │   1    │   2    │   3    │   4    │ ) AA\n│0x01 │   4    │   0    │   1    │   2    │   3    │ ) AA~\n│0x02 │   5    │   6    │   7    │   8    │   9    │ ) AB\n│0x03 │   9    │   5    │   6    │   7    │   8    │ ) AB~\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│ :   │   :    │   :    │   :    │   :    │   :    │   :\n│     │  ...   │  ...   │  ...   │  ...   │  ...   │ ...\n│0x79 │  314   │  315   │  316   │  317   │  318   │ ) EX\n│0x80 │  318   │  314   │  315   │  316   │  317   │ ) EX~\n└─────└────────└────────└────────└────────└────────┘\n\nWith AA, AB, ..., AZ, BA, ... being the sets of <number of devices> consecutive chunks\nand AA~, AB~, ..., AZ~, BA~, ... the cyclic permutations with offset 1 thereof (in the\ncase  of  more  than  2  copies  per  chunk  there  would  be  (AA~)~, ...  as well as\n((AA~)~)~, ... and so on).\n\nThis should give similar read characteristics to \"far\" if a suitably large chunk  size\nis used, but without as much seeking for writes.\n\nIt should be noted that the number of devices in a RAID10 array need not be a multiple of the\nnumber of replica of each data block; however, there must be at  least  as  many  devices  as\nreplicas.\n\nIf,  for example, an array is created with 5 devices and 2 replicas, then space equivalent to\n2.5 of the devices will be available, and every block will be stored  on  two  different  de‐\nvices.\n\nFinally,  it  is possible to have an array with both \"near\" and \"far\" copies.  If an array is\nconfigured with 2 near copies and 2 far copies, then there will be a total  of  4  copies  of\neach  block, each on a different drive.  This is an artifact of the implementation and is un‐\nlikely to be of real value.\n\n\nMULTIPATH\nMULTIPATH is not really a RAID at all as there is only one real device in a MULTIPATH md  ar‐\nray.  However there are multiple access points (paths) to this device, and one of these paths\nmight fail, so there are some similarities.\n\nA MULTIPATH array is composed of a number of logically different devices, often fibre channel\ninterfaces,  that  all refer the the same real device. If one of these interfaces fails (e.g.\ndue to cable problems), the MULTIPATH driver will attempt to redirect requests to another in‐\nterface.\n\nThe  MULTIPATH  drive  is  not  receiving  any ongoing development and should be considered a\nlegacy driver.  The device-mapper based multipath drivers should be preferred for new instal‐\nlations.\n\n\nFAULTY\nThe FAULTY md module is provided for testing purposes.  A FAULTY array has exactly one compo‐\nnent device and is normally assembled without a superblock, so the md array created  provides\ndirect access to all of the data in the component device.\n\nThe  FAULTY module may be requested to simulate faults to allow testing of other md levels or\nof filesystems.  Faults can be chosen to trigger on read requests or write requests, and  can\nbe  transient  (a  subsequent  read/write at the address will probably succeed) or persistent\n(subsequent read/write of the same address will fail).  Further, read faults can be \"fixable\"\nmeaning that they persist until a write request at the same address.\n\nFault  types  can  be requested with a period.  In this case, the fault will recur repeatedly\nafter the given number of requests of the relevant type.   For  example  if  persistent  read\nfaults  have  a  period of 100, then every 100th read request would generate a fault, and the\nfaulty sector would be recorded so that subsequent reads on that sector would also fail.\n\nThere is a limit to the number of faulty sectors that are remembered.  Faults generated after\nthis limit is exhausted are treated as transient.\n\nThe  list  of  faulty  sectors  can  be  flushed, and the active list of failure modes can be\ncleared.\n\n\nUNCLEAN SHUTDOWN\nWhen changes are made to a RAID1, RAID4, RAID5, RAID6, or RAID10 array there is a possibility\nof  inconsistency  for short periods of time as each update requires at least two block to be\nwritten to different devices, and these writes probably won't  happen  at  exactly  the  same\ntime.   Thus if a system with one of these arrays is shutdown in the middle of a write opera‐\ntion (e.g. due to power failure), the array may not be consistent.\n\nTo handle this situation, the md driver marks an array as \"dirty\" before writing any data  to\nit,  and  marks  it as \"clean\" when the array is being disabled, e.g. at shutdown.  If the md\ndriver finds an array to be dirty at startup, it proceeds to correct any  possibly  inconsis‐\ntency.   For  RAID1,  this  involves  copying  the contents of the first drive onto all other\ndrives.  For RAID4, RAID5 and RAID6 this involves recalculating the parity  for  each  stripe\nand  making  sure that the parity block has the correct data.  For RAID10 it involves copying\none of the replicas of each block onto all the others.  This process, known as \"resynchronis‐\ning\"  or \"resync\" is performed in the background.  The array can still be used, though possi‐\nbly with reduced performance.\n\nIf a RAID4, RAID5 or RAID6 array is degraded (missing at least one drive, two for RAID6) when\nit  is restarted after an unclean shutdown, it cannot recalculate parity, and so it is possi‐\nble that data might be undetectably corrupted.  The 2.4 md driver does not alert the operator\nto  this  condition.  The 2.6 md driver will fail to start an array in this condition without\nmanual intervention, though this behaviour can be overridden by a kernel parameter.\n\n\nRECOVERY\nIf the md driver detects a write error on a device in a RAID1, RAID4, RAID5, RAID6, or RAID10\narray,  it immediately disables that device (marking it as faulty) and continues operation on\nthe remaining devices.  If there are spare drives, the driver will start recreating on one of\nthe  spare  drives the data which was on that failed drive, either by copying a working drive\nin a RAID1 configuration, or by doing calculations with the parity block on RAID4,  RAID5  or\nRAID6, or by finding and copying originals for RAID10.\n\nIn  kernels prior to about 2.6.15, a read error would cause the same effect as a write error.\nIn later kernels, a read-error will instead cause md to attempt a recovery by overwriting the\nbad  block.  i.e.  it will find the correct data from elsewhere, write it over the block that\nfailed, and then try to read it back again.  If either the write or the re-read fail, md will\ntreat the error the same way that a write error is treated, and will fail the whole device.\n\nWhile  this  recovery  process is happening, the md driver will monitor accesses to the array\nand will slow down the rate of recovery if other activity is happening, so that normal access\nto  the array will not be unduly affected.  When no other activity is happening, the recovery\nprocess proceeds at full speed.  The actual speed targets for the  two  different  situations\ncan be controlled by the speedlimitmin and speedlimitmax control files mentioned below.\n\n\nSCRUBBING AND MISMATCHES\nAs  storage  devices  can develop bad blocks at any time it is valuable to regularly read all\nblocks on all devices in an array so as to catch such bad  blocks  early.   This  process  is\ncalled scrubbing.\n\nmd arrays can be scrubbed by writing either check or repair to the file md/syncaction in the\nsysfs directory for the device.\n\nRequesting a scrub will cause md to read every block on every device in the array, and  check\nthat  the  data is consistent.  For RAID1 and RAID10, this means checking that the copies are\nidentical.  For RAID4, RAID5, RAID6 this means checking that the parity block is  (or  blocks\nare) correct.\n\nIf  a  read error is detected during this process, the normal read-error handling causes cor‐\nrect data to be found from other devices and to be written back to  the  faulty  device.   In\nmany case this will effectively fix the bad block.\n\nIf  all blocks read successfully but are found to not be consistent, then this is regarded as\na mismatch.\n\nIf check was used, then no action is taken to handle the mismatch, it is simply recorded.  If\nrepair was used, then a mismatch will be repaired in the same way that resync repairs arrays.\nFor RAID5/RAID6 new parity blocks are written.  For RAID1/RAID10, all but one block are over‐\nwritten with the content of that one block.\n\nA  count  of  mismatches  is recorded in the sysfs file md/mismatchcnt.  This is set to zero\nwhen a scrub starts and is incremented whenever a sector is found that  is  a  mismatch.   md\nnormally  works  in  units  much larger than a single sector and when it finds a mismatch, it\ndoes not determine exactly how many actual sectors were affected but simply adds  the  number\nof  sectors  in the IO unit that was used.  So a value of 128 could simply mean that a single\n64KB check found an error (128 x 512bytes = 64KB).\n\nIf an array is created by mdadm with --assume-clean then a subsequent check could be expected\nto find some mismatches.\n\nOn  a  truly clean RAID5 or RAID6 array, any mismatches should indicate a hardware problem at\nsome level - software issues should never cause such a mismatch.\n\nHowever on RAID1 and RAID10 it is possible for software issues to cause a mismatch to be  re‐\nported.   This  does  not necessarily mean that the data on the array is corrupted.  It could\nsimply be that the system does not care what is stored on that part of the array - it is  un‐\nused space.\n\nThe  most  likely cause for an unexpected mismatch on RAID1 or RAID10 occurs if a swap parti‐\ntion or swap file is stored on the array.\n\nWhen the swap subsystem wants to write a page of memory out, it flags the page as 'clean'  in\nthe  memory  manager and requests the swap device to write it out.  It is quite possible that\nthe memory will be changed while the write-out is happening.  In that case the  'clean'  flag\nwill be found to be clear when the write completes and so the swap subsystem will simply for‐\nget that the swapout had been attempted, and will possibly choose a different page  to  write\nout.\n\nIf  the  swap  device was on RAID1 (or RAID10), then the data is sent from memory to a device\ntwice (or more depending on the number of devices in the array).  Thus it  is  possible  that\nthe memory gets changed between the times it is sent, so different data can be written to the\ndifferent devices in the array.  This will be detected by check as a  mismatch.   However  it\ndoes  not  reflect any corruption as the block where this mismatch occurs is being treated by\nthe swap system as being empty, and the data will never be read from that block.\n\nIt is conceivable for a similar situation to occur on  non-swap  files,  though  it  is  less\nlikely.\n\nThus  the  mismatchcnt  value can not be interpreted very reliably on RAID1 or RAID10, espe‐\ncially when the device is used for swap.\n\n\n\nBITMAP WRITE-INTENT LOGGING\nFrom Linux 2.6.13, md supports a bitmap based write-intent log.  If configured, the bitmap is\nused  to  record  which  blocks of the array may be out of sync.  Before any write request is\nhonoured, md will make sure that the corresponding bit in the log is set.  After a period  of\ntime with no writes to an area of the array, the corresponding bit will be cleared.\n\nThis bitmap is used for two optimisations.\n\nFirstly,  after  an  unclean  shutdown,  the  resync process will consult the bitmap and only\nresync those blocks that correspond to bits in the bitmap that are set.   This  can  dramati‐\ncally reduce resync time.\n\nSecondly, when a drive fails and is removed from the array, md stops clearing bits in the in‐\ntent log.  If that same drive is re-added to the array, md will notice and will only  recover\nthe  sections of the drive that are covered by bits in the intent log that are set.  This can\nallow a device to be temporarily removed and reinserted without causing an enormous  recovery\ncost.\n\nThe intent log can be stored in a file on a separate device, or it can be stored near the su‐\nperblocks of an array which has superblocks.\n\nIt is possible to add an intent log to an active array, or remove an intent  log  if  one  is\npresent.\n\nIn  2.6.13,  intent  bitmaps are only supported with RAID1.  Other levels with redundancy are\nsupported from 2.6.15.\n\n\nBAD BLOCK LIST\nFrom Linux 3.5 each device in an md array can store a list of known-bad-blocks.  This list is\n4K  in  size  and  usually  positioned at the end of the space between the superblock and the\ndata.\n\nWhen a block cannot be read and cannot be repaired by writing data recovered from  other  de‐\nvices,  the address of the block is stored in the bad block list.  Similarly if an attempt to\nwrite a block fails, the address will be recorded as a bad block.  If  attempting  to  record\nthe bad block fails, the whole device will be marked faulty.\n\nAttempting  to read from a known bad block will cause a read error.  Attempting to write to a\nknown bad block will be ignored if any write errors have been reported  by  the  device.   If\nthere  have  been no write errors then the data will be written to the known bad block and if\nthat succeeds, the address will be removed from the list.\n\nThis allows an array to fail more gracefully - a few  blocks  on  different  devices  can  be\nfaulty without taking the whole array out of action.\n\nThe  list  is particularly useful when recovering to a spare.  If a few blocks cannot be read\nfrom the other devices, the bulk of the recovery can complete and those few bad  blocks  will\nbe recorded in the bad block list.\n\n\nRAID WRITE HOLE\nDue  to non-atomicity nature of RAID write operations, interruption of write operations (sys‐\ntem crash, etc.) to RAID456 array can lead to inconsistent parity and data  loss  (so  called\nRAID-5 write hole).  To plug the write hole md supports two mechanisms described below.\n\n\nDIRTY STRIPE JOURNAL\nFrom  Linux  4.4, md supports write ahead journal for RAID456.  When the array is cre‐\nated, an additional journal device can be added to the array through write-journal op‐\ntion.  The RAID write journal works similar to file system journals. Before writing to\nthe data disks, md persists data AND parity of the stripe to the journal device. After\ncrashes,  md  searches  the journal device for incomplete write operations, and replay\nthem to the data disks.\n\nWhen the journal device fails, the RAID array is forced to run in read-only mode.\n\n\nPARTIAL PARITY LOG\nFrom Linux 4.12 md supports Partial Parity Log (PPL) for RAID5 arrays  only.   Partial\nparity  for  a  write  operation  is the XOR of stripe data chunks not modified by the\nwrite. PPL is stored in the metadata region of RAID member drives, no additional jour‐\nnal  drive  is  needed.   After  crashes, if one of the not modified data disks of the\nstripe is missing, this updated parity can be used to recover its data.\n\nThis mechanism is documented more fully in the file Documentation/md/raid5-ppl.rst\n\n\nWRITE-BEHIND\nFrom Linux 2.6.14, md supports WRITE-BEHIND on RAID1 arrays.\n\nThis allows certain devices in the array to be flagged as write-mostly.  MD  will  only  read\nfrom such devices if there is no other option.\n\nIf  a  write-intent  bitmap  is also provided, write requests to write-mostly devices will be\ntreated as write-behind requests and md will not wait for writes to those  requests  to  com‐\nplete before reporting the write as complete to the filesystem.\n\nThis allows for a RAID1 with WRITE-BEHIND to be used to mirror data over a slow link to a re‐\nmote computer (providing the link isn't too slow).  The extra latency of the remote link will\nnot  slow  down  normal operations, but the remote system will still have a reasonably up-to-\ndate copy of all data.\n\n\nFAILFAST\nFrom Linux 4.10, md supports FAILFAST for RAID1 and RAID10 arrays.  This is a flag  that  can\nbe set on individual drives, though it is usually set on all drives, or no drives.\n\nWhen  md sends an I/O request to a drive that is marked as FAILFAST, and when the array could\nsurvive the loss of that drive without losing data, md will request that the  underlying  de‐\nvice  does  not  perform  any  retries.   This  means  that  a failure will be reported to md\npromptly, and it can mark the device as faulty and continue using the  other  device(s).   md\ncannot control the timeout that the underlying devices use to determine failure.  Any changes\ndesired to that timeout must be set explicitly on the underlying device, separately from  us‐\ning mdadm.\n\nIf a FAILFAST request does fail, and if it is still safe to mark the device as faulty without\ndata loss, that will be done and the array will continue functioning on a reduced  number  of\ndevices.   If  it  is not possible to safely mark the device as faulty, md will retry the re‐\nquest without disabling retries in the underlying device.  In any case, md will  not  attempt\nto  repair  read  errors  on a device marked as FAILFAST by writing out the correct.  It will\njust mark the device as faulty.\n\nFAILFAST is appropriate for storage arrays that have a low probability of true  failure,  but\nwill  sometimes introduce unacceptable delays to I/O requests while performing internal main‐\ntenance.  The value of setting FAILFAST involves a trade-off.  The gain is that the chance of\nunacceptable  delays  is substantially reduced.  The cost is that the unlikely event of data-\nloss on one device is slightly more likely to result in data-loss for the array.\n\nWhen a device in an array using FAILFAST is marked as faulty, it will usually  become  usable\nagain  in  a  short while.  mdadm makes no attempt to detect that possibility.  Some separate\nmechanism, tuned to the specific details of the expected failure modes, needs to  be  created\nto  monitor devices to see when they return to full functionality, and to then re-add them to\nthe array.  In order of this \"re-add\" functionality to be effective, an array using  FAILFAST\nshould always have a write-intent bitmap.\n\n\nRESTRIPING\nRestriping, also known as Reshaping, is the processes of re-arranging the data stored in each\nstripe into a new layout.  This might involve changing the number of devices in the array (so\nthe  stripes  are  wider),  changing  the chunk size (so stripes are deeper or shallower), or\nchanging the arrangement of data and parity (possibly changing the RAID level, e.g. 1 to 5 or\n5 to 6).\n\nAs  of Linux 2.6.35, md can reshape a RAID4, RAID5, or RAID6 array to have a different number\nof devices (more or fewer) and to have a different layout or chunk size.  It can also convert\nbetween  these  different RAID levels.  It can also convert between RAID0 and RAID10, and be‐\ntween RAID0 and RAID4 or RAID5.  Other possibilities may follow in future kernels.\n\nDuring any stripe process there is a 'critical section' during which live data is being over‐\nwritten on disk.  For the operation of increasing the number of drives in a RAID5, this crit‐\nical section covers the first few stripes (the number being the product of the  old  and  new\nnumber  of devices).  After this critical section is passed, data is only written to areas of\nthe array which no longer hold live data — the live data has already been located away.\n\nFor a reshape which reduces the number of devices, the 'critical section' is at  the  end  of\nthe reshape process.\n\nmd  is  not  able to ensure data preservation if there is a crash (e.g. power failure) during\nthe critical section.  If md is asked to start an array which failed during a  critical  sec‐\ntion of restriping, it will fail to start the array.\n\nTo deal with this possibility, a user-space program must\n\n•   Disable writes to that section of the array (using the sysfs interface),\n\n•   take a copy of the data somewhere (i.e. make a backup),\n\n•   allow the process to continue and invalidate the backup and restore write access once the\ncritical section is passed, and\n\n•   provide for restoring the critical data before restarting the array after a system crash.\n\nmdadm versions from 2.4 do this for growing a RAID5 array.\n\nFor operations that do not change the size of the array, like simply increasing  chunk  size,\nor  converting  RAID5 to RAID6 with one extra device, the entire process is the critical sec‐\ntion.  In this case, the restripe will need to progress in stages, as a section is suspended,\nbacked up, restriped, and released.\n\n\nSYSFS INTERFACE\nEach block device appears as a directory in sysfs (which is usually mounted at /sys).  For MD\ndevices, this directory will contain a subdirectory called md which  contains  various  files\nfor providing access to information about the array.\n\nThis interface is documented more fully in the file Documentation/admin-guide/md.rst which is\ndistributed with the kernel sources.  That file should be consulted for  full  documentation.\nThe following are just a selection of attribute files that are available.\n\n\nmd/syncspeedmin\nThis     value,     if     set,     overrides     the     system-wide    setting    in\n/proc/sys/dev/raid/speedlimitmin for this array only.  Writing the value  system  to\nthis file will cause the system-wide setting to have effect.\n\n\nmd/syncspeedmax\nThis      is      the      partner      of     md/syncspeedmin     and     overrides\n/proc/sys/dev/raid/speedlimitmax described below.\n\n\nmd/syncaction\nThis can be used to monitor and control the resync/recovery process of MD.  In partic‐\nular,  writing \"check\" here will cause the array to read all data block and check that\nthey are consistent (e.g. parity is correct, or all mirror  replicas  are  the  same).\nAny discrepancies found are NOT corrected.\n\nA count of problems found will be stored in md/mismatchcount.\n\nAlternately,  \"repair\" can be written which will cause the same check to be performed,\nbut any errors will be corrected.\n\nFinally, \"idle\" can be written to stop the check/repair process.\n\n\nmd/stripecachesize\nThis is only available on RAID5 and RAID6.  It records the size (in pages per  device)\nof the  stripe cache which is used for synchronising all write operations to the array\nand all read operations if the array is degraded.  The default is 256.   Valid  values\nare  17 to 32768.  Increasing this number can increase performance in some situations,\nat some cost in system memory.  Note, setting this value too high  can  result  in  an\n\"out of memory\" condition for the system.\n\nmemoryconsumed = systempagesize * nrdisks * stripecachesize\n\n\nmd/prereadbypassthreshold\nThis  is only available on RAID5 and RAID6.  This variable sets the number of times MD\nwill service a full-stripe-write before servicing a stripe that  requires  some  \"pre‐\nreading\".   For fairness this defaults to 1.  Valid values are 0 to stripecachesize.\nSetting this to 0 maximizes sequential-write throughput at the  cost  of  fairness  to\nthreads doing small or random writes.\n\n#### md/bitmap/backlog\n\nThe  value  stored  in the file only has any effect on RAID1 when write-mostly devices\nare active, and write requests to those devices are proceed in the background.\n\nThis variable sets a limit on the number of concurrent background  writes,  the  valid\nvalues  are 0 to 16383, 0 means that write-behind is not allowed, while any other num‐\nber means it can happen.  If there are more write requests than the number, new writes\nwill by synchronous.\n\n\nmd/bitmap/canclear\nThis is for externally managed bitmaps, where the kernel writes the bitmap itself, but\nmetadata describing the bitmap is managed by mdmon or similar.\n\nWhen the array is degraded, bits mustn't be cleared. When the  array  becomes  optimal\nagain,  bit  can  be cleared, but first the metadata needs to record the current event\ncount. So md sets this to 'false' and notifies mdmon, then mdmon updates the  metadata\nand writes 'true'.\n\nThere is no code in mdmon to actually do this, so maybe it doesn't even work.\n\n#### md/bitmap/chunksize\n\nThe  bitmap  chunksize  can  only  be  changed when no bitmap is active, and the value\nshould be power of 2 and at least 512.\n\n#### md/bitmap/location\n\nThis indicates where the write-intent bitmap for the  array  is  stored.   It  can  be\n\"none\" or \"file\" or a signed offset from the array metadata - measured in sectors. You\ncannot set a file by writing here - that can only be  done  with  the  SETBITMAPFILE\nioctl.\n\nWrite  'none'  to 'bitmap/location' will clear bitmap, and the previous location value\nmust be write to it to restore bitmap.\n\n\nmd/bitmap/maxbacklogused\nThis keeps track of the maximum number of concurrent write-behind requests for  an  md\narray, writing any value to this file will clear it.\n\n#### md/bitmap/metadata\n\nThis  can  be  'internal'  or 'clustered' or 'external'. 'internal' is set by default,\nwhich means the metadata for bitmap is stored in the first 256  bytes  of  the  bitmap\nspace. 'clustered' means separate bitmap metadata are used for each cluster node. 'ex‐\nternal' means that bitmap metadata is managed externally to the kernel.\n\n#### md/bitmap/space\n\nThis shows the space (in sectors) which is available at md/bitmap/location, and allows\nthe  kernel  to know when it is safe to resize the bitmap to match a resized array. It\nshould big enough to contain the total bytes in the bitmap.\n\nFor 1.0 metadata, assume we can use up to the superblock if before, else to 4K  beyond\nsuperblock. For other metadata versions, assume no change is possible.\n\n\nmd/bitmap/timebase\nThis shows the time (in seconds) between disk flushes, and is used to looking for bits\nin the bitmap to be cleared.\n\nThe default value is 5 seconds, and it should be an unsigned long value.\n\n\nKERNEL PARAMETERS\nThe md driver recognised several different kernel parameters.\n\n#### raid=noautodetect\n\nThis will disable the normal detection of md arrays that happens at boot time.   If  a\ndrive  is  partitioned  with MS-DOS style partitions, then if any of the 4 main parti‐\ntions has a partition type of 0xFD, then that partition will normally be inspected  to\nsee  if it is part of an MD array, and if any full arrays are found, they are started.\nThis kernel parameter disables this behaviour.\n\n#### raid=partitionable\n\n#### raid=part\n\nThese are available in 2.6 and later kernels only.  They indicate that autodetected MD\narrays should be created as partitionable arrays, with a different major device number\nto the original non-partitionable md arrays.  The device number is listed  as  mdp  in\n/proc/devices.\n\n\nmdmod.startro=1\n\n/sys/module/mdmod/parameters/startro\nThis  tells  md  to start all arrays in read-only mode.  This is a soft read-only that\nwill automatically switch to read-write on the first  write  request.   However  until\nthat  write  request,  nothing  is  written to any device by md, and in particular, no\nresync or recovery operation is started.\n\n\nmdmod.startdirtydegraded=1\n\n/sys/module/mdmod/parameters/startdirtydegraded\nAs mentioned above, md will not normally start a RAID4, RAID5, or RAID6 that  is  both\ndirty  and degraded as this situation can imply hidden data loss.  This can be awkward\nif the root filesystem is affected.  Using this module parameter allows such arrays to\nbe  started at boot time.  It should be understood that there is a real (though small)\nrisk of data corruption in this situation.\n\n\nmd=n,dev,dev,...\n\nmd=dn,dev,dev,...\nThis tells the md driver to assemble /dev/md n from the listed devices.   It  is  only\nnecessary  to start the device holding the root filesystem this way.  Other arrays are\nbest started once the system is booted.\n\nIn 2.6 kernels, the d immediately after the = indicates that  a  partitionable  device\n(e.g.   /dev/md/d0)  should  be created rather than the original non-partitionable de‐\nvice.\n\n\nmd=n,l,c,i,dev...\nThis tells the md driver to assemble a legacy RAID0 or  LINEAR  array  without  a  su‐\nperblock.  n gives the md device number, l gives the level, 0 for RAID0 or -1 for LIN‐\nEAR, c gives the chunk size as a base-2 logarithm offset by twelve, so 0 means  4K,  1\nmeans 8K.  i is ignored (legacy support).\n\n### FILES\n\n#### /proc/mdstat\n\nContains information about the status of currently running array.\n\n/proc/sys/dev/raid/speedlimitmin\nA  readable and writable file that reflects the current \"goal\" rebuild speed for times\nwhen non-rebuild activity is current on an array.  The speed is in Kibibytes per  sec‐\nond,  and  is  a per-device rate, not a per-array rate (which means that an array with\nmore disks will shuffle more data for a given speed).   The default is 1000.\n\n\n/proc/sys/dev/raid/speedlimitmax\nA readable and writable file that reflects the current \"goal\" rebuild speed for  times\nwhen no non-rebuild activity is current on an array.  The default is 200,000.\n\n### SEE ALSO\n\nmdadm(8),\n\n\n\nMD(4)\n\n"
        }
    ],
    "structuredContent": {
        "command": "md",
        "section": "4",
        "mode": "man",
        "summary": "md - Multiple Device driver aka Linux Software RAID",
        "synopsis": "/dev/mdn\n/dev/md/n\n/dev/md/name",
        "tldr_summary": null,
        "tldr_examples": [],
        "tldr_source": null,
        "flags": [],
        "examples": [],
        "see_also": [
            {
                "name": "mdadm",
                "section": "8",
                "url": "https://www.chedong.com/phpMan.php/man/mdadm/8/json"
            },
            {
                "name": "MD",
                "section": "4",
                "url": "https://www.chedong.com/phpMan.php/man/MD/4/json"
            }
        ],
        "section_outline": [
            {
                "name": "NAME",
                "lines": 2,
                "subsections": []
            },
            {
                "name": "SYNOPSIS",
                "lines": 4,
                "subsections": []
            },
            {
                "name": "DESCRIPTION",
                "lines": 217,
                "subsections": [
                    {
                        "name": "About the RAID10 Layout Examples:",
                        "lines": 16
                    },
                    {
                        "name": "\"near\" Layout",
                        "lines": 41
                    },
                    {
                        "name": "\"far\" Layout",
                        "lines": 66
                    },
                    {
                        "name": "\"offset\" Layout",
                        "lines": 451
                    },
                    {
                        "name": "md/bitmap/backlog",
                        "lines": 21
                    },
                    {
                        "name": "md/bitmap/chunksize",
                        "lines": 4
                    },
                    {
                        "name": "md/bitmap/location",
                        "lines": 14
                    },
                    {
                        "name": "md/bitmap/metadata",
                        "lines": 6
                    },
                    {
                        "name": "md/bitmap/space",
                        "lines": 18
                    },
                    {
                        "name": "raid=noautodetect",
                        "lines": 7
                    },
                    {
                        "name": "raid=partitionable",
                        "lines": 1
                    },
                    {
                        "name": "raid=part",
                        "lines": 44
                    }
                ]
            },
            {
                "name": "FILES",
                "lines": 1,
                "subsections": [
                    {
                        "name": "/proc/mdstat",
                        "lines": 14
                    }
                ]
            },
            {
                "name": "SEE ALSO",
                "lines": 5,
                "subsections": []
            }
        ]
    }
}