diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-11-09 11:41:33 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-11-09 11:41:33 +0000 |
commit | e9922970d313f8bbf5440586f3020904ff7e057c (patch) | |
tree | 24090f3abf9370a2ff1ba6327d8c06c068f9c171 /md.4 | |
parent | Releasing debian version 4.3+20240723-2. (diff) | |
download | mdadm-e9922970d313f8bbf5440586f3020904ff7e057c.tar.xz mdadm-e9922970d313f8bbf5440586f3020904ff7e057c.zip |
Merging upstream version 4.3+20241108.
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'md.4')
-rw-r--r-- | md.4 | 67 |
1 files changed, 15 insertions, 52 deletions
@@ -48,11 +48,9 @@ stored in the device. This metadata is sometimes called a The metadata records information about the structure and state of the array. This allows the array to be reliably re-assembled after a shutdown. -From Linux kernel version 2.6.10, .B md provides support for two different formats of metadata, and -other formats can be added. Prior to this release, only one format is -supported. +other formats can be added. The common format \(em known as version 0.90 \(em has a superblock that is 4K long and is written into a 64K aligned block that @@ -126,7 +124,6 @@ have special-purpose uses and is supported. .SS ARRAYS WITH EXTERNAL METADATA -From release 2.6.28, the .I md driver supports arrays with externally managed metadata. That is, the metadata is not managed by the kernel but rather by a user-space @@ -178,8 +175,7 @@ A RAID0 array (which has zero redundancy) is also known as a striped array. A RAID0 array is configured at creation with a .B "Chunk Size" -which must be a power of two (prior to Linux 2.6.31), and at least 4 -kibibytes. +which must be at least 4 kibibytes. The RAID0 driver assigns the first chunk of the array to the first device, the second chunk to the second device, and so on until all @@ -224,7 +220,7 @@ option. If you use this option to while running a newer kernel, the array will NOT assemble, but the metadata will be update so that it can be assembled on an older kernel. -No that setting the layout to "unspecified" removes protections against +Note that setting the layout to "unspecified" removes protections against this bug, and you must be sure that the kernel you use matches the layout of the array. @@ -303,8 +299,7 @@ drives. When configuring a RAID10 array, it is necessary to specify the number of replicas of each data block that are required (this will usually -be\ 2) and whether their layout should be "near", "far" or "offset" -(with "offset" being available since Linux\ 2.6.18). +be\ 2) and whether their layout should be "near", "far" or "offset". .B About the RAID10 Layout Examples: .br @@ -707,9 +702,7 @@ The array can still be used, though possibly with reduced performance. If a RAID4, RAID5 or RAID6 array is degraded (missing at least one drive, two for RAID6) when it is restarted after an unclean shutdown, it cannot recalculate parity, and so it is possible that data might be -undetectably corrupted. The 2.4 md driver -.B does not -alert the operator to this condition. The 2.6 md driver will fail to +undetectably corrupted. The md driver will fail to start an array in this condition without manual intervention, though this behaviour can be overridden by a kernel parameter. @@ -724,12 +717,9 @@ either by copying a working drive in a RAID1 configuration, or by doing calculations with the parity block on RAID4, RAID5 or RAID6, or by finding and copying originals for RAID10. -In kernels prior to about 2.6.15, a read error would cause the same -effect as a write error. In later kernels, a read-error will instead -cause md to attempt a recovery by overwriting the bad block. i.e. it -will find the correct data from elsewhere, write it over the block -that failed, and then try to read it back again. If either the write -or the re-read fail, md will treat the error the same way that a write +A read-error will cause md to attempt a recovery by overwriting the bad block. i.e. it will find +the correct data from elsewhere, write it over the block that failed, and then try to read it back +again. If either the write or the re-read fail, md will treat the error the same way that a write error is treated, and will fail the whole device. While this recovery process is happening, the md driver will monitor @@ -851,7 +841,6 @@ especially when the device is used for swap. .SS BITMAP WRITE-INTENT LOGGING -From Linux 2.6.13, .I md supports a bitmap based write-intent log. If configured, the bitmap is used to record which blocks of the array may be out of sync. @@ -878,12 +867,11 @@ be stored near the superblocks of an array which has superblocks. It is possible to add an intent log to an active array, or remove an intent log if one is present. -In 2.6.13, intent bitmaps are only supported with RAID1. Other levels -with redundancy are supported from 2.6.15. +All raid levels with redundancy are supported. .SS BAD BLOCK LIST -From Linux 3.5 each device in an +Each device in an .I md array can store a list of known-bad-blocks. This list is 4K in size and usually positioned at the end of the space between the superblock @@ -937,18 +925,12 @@ Partial parity for a write operation is the XOR of stripe data chunks not modified by the write. PPL is stored in the metadata region of RAID member drives, no additional journal drive is needed. After crashes, if one of the not modified data disks of -the stripe is missing, this updated parity can be used to recover its -data. +the stripe is missing, this updated parity can be used to recover its data. -This mechanism is documented more fully in the file -Documentation/md/raid5-ppl.rst +See Documentation/driver-api/md/raid5-ppl.rst for implementation details. .SS WRITE-BEHIND -From Linux 2.6.14, -.I md -supports WRITE-BEHIND on RAID1 arrays. - This allows certain devices in the array to be flagged as .IR write-mostly . MD will only read from such devices if there is no @@ -1030,7 +1012,8 @@ array (so the stripes are wider), changing the chunk size (so stripes are deeper or shallower), or changing the arrangement of data and parity (possibly changing the RAID level, e.g. 1 to 5 or 5 to 6). -As of Linux 2.6.35, md can reshape a RAID4, RAID5, or RAID6 array to +.I md +can reshape a RAID4, RAID5, or RAID6 array to have a different number of devices (more or fewer) and to have a different layout or chunk size. It can also convert between these different RAID levels. It can also convert between RAID0 and RAID10, @@ -1069,7 +1052,7 @@ after a system crash. .PP .B mdadm -versions from 2.4 do this for growing a RAID5 array. +do this for growing a RAID5 array. For operations that do not change the size of the array, like simply increasing chunk size, or converting RAID5 to RAID6 with one extra @@ -1231,18 +1214,6 @@ an MD array, and if any full arrays are found, they are started. This kernel parameter disables this behaviour. .TP -.B raid=partitionable -.TP -.B raid=part -These are available in 2.6 and later kernels only. They indicate that -autodetected MD arrays should be created as partitionable arrays, with -a different major device number to the original non-partitionable md -arrays. The device number is listed as -.I mdp -in -.IR /proc/devices . - -.TP .B md_mod.start_ro=1 .TP .B /sys/module/md_mod/parameters/start_ro @@ -1273,14 +1244,6 @@ from the listed devices. It is only necessary to start the device holding the root filesystem this way. Other arrays are best started once the system is booted. -In 2.6 kernels, the -.B d -immediately after the -.B = -indicates that a partitionable device (e.g. -.BR /dev/md/d0 ) -should be created rather than the original non-partitionable device. - .TP .BI md= n , l , c , i , dev... This tells the md driver to assemble a legacy RAID0 or LINEAR array |