fix: segfault when killing subarray of non-existent container

[thirdparty/mdadm.git] / mdadm.8.in

diff --git a/mdadm.8.in b/mdadm.8.in
index d56cd98754be41d96617fdd9f9a5e09abb4ae559..e22fde4c4bb8def0003cf8e9f303c4c5c31a0373 100644 (file)
--- a/mdadm.8.in
+++ b/mdadm.8.in
@@ -418,11 +418,22 @@ issued.
 A suffix of 'M' or 'G' can be given to indicate Megabytes or
 Gigabytes respectively.
 
+Sometimes a replacement drive can be a little smaller than the
+original drives though this should be minimised by IDEMA standards.
+Such a replacement drive will be rejected by
+.IR md .
+To guard against this it can be useful to set the initial size
+slightly smaller than the smaller device with the aim that it will
+still be larger than any replacement.
+
 This value can be set with
 .B \-\-grow
-for RAID level 1/4/5/6.  If the array was created with a size smaller
-than the currently active drives, the extra space can be accessed
-using
+for RAID level 1/4/5/6 though
+.B CONTAINER
+based arrays such as those with IMSM metadata may not be able to
+support this.
+If the array was created with a size smaller than the currently
+active drives, the extra space can be accessed using
 .BR \-\-grow .
 The size can be given as
 .B max
@@ -440,9 +451,10 @@ problems the array can be made bigger again with no loss with another
 .B "\-\-grow \-\-size="
 command.
 
-This value can not be used with
+This value cannot be used when creating a
 .B CONTAINER
-metadata such as DDF and IMSM.
+such as with DDF and IMSM metadata, though it perfectly valid when
+creating an array inside a container.
 
 .TP
 .BR \-Z ", " \-\-array\-size=
@@ -1496,7 +1508,7 @@ the first device given is the md device.
 In the second usage example, all devices listed are treated as md
 devices and assembly is attempted.
 In the third (where no devices are listed) all md devices that are
-listed in the configuration file are assembled.  If not arrays are
+listed in the configuration file are assembled.  If no arrays are
 described by the configuration file, then any arrays that
 can be found on unused devices will be assembled.
 
@@ -1605,7 +1617,7 @@ and no devices are listed,
 will first attempt to assemble all the arrays listed in the config
 file.
 
-In no array at listed in the config (other than those marked
+If no arrays are listed in the config (other than those marked
 .BR <ignore> )
 it will look through the available devices for possible arrays and
 will try to assemble anything that it finds.  Arrays which are tagged
@@ -2205,22 +2217,24 @@ change the "size" attribute for RAID1, RAID4, RAID5 and RAID6.
 .IP \(bu 4
 increase or decrease the "raid\-devices" attribute of RAID0, RAID1, RAID4,
 RAID5, and RAID6.
-.IP \bu 4
+.IP \(bu 4
 change the chunk-size and layout of RAID0, RAID4, RAID5 and RAID6.
-.IP \bu 4
+.IP \(bu 4
 convert between RAID1 and RAID5, between RAID5 and RAID6, between
-RAID0, RAID5, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).
+RAID0, RAID4, and RAID5, and between RAID0 and RAID10 (in the near-2 mode).
 .IP \(bu 4
 add a write-intent bitmap to any array which supports these bitmaps, or
 remove a write-intent bitmap from such an array.
 .PP
 
-Using GROW on containers is currently only support for Intel's IMSM
+Using GROW on containers is currently supported only for Intel's IMSM
 container format.  The number of devices in a container can be
 increased - which affects all arrays in the container - or an array
 in a container can be converted between levels where those levels are
 supported by the container, and the conversion is on of those listed
-above.
+above.  Resizing arrays in an IMSM container with
+.B "--grow --size"
+is not yet supported.
 
 Grow functionality (e.g. expand a number of raid devices) for Intel's
 IMSM container format has an experimental status. It is guarded by the
@@ -2255,7 +2269,7 @@ space to start being used.  If the size is increased in this way, a
 are synchronised.
 
 Note that when an array changes size, any filesystem that may be
-stored in the array will not automatically grow for shrink to use or
+stored in the array will not automatically grow or shrink to use or
 vacate the space.  The
 filesystem will need to be explicitly told to use the extra space
 after growing, or to reduce its size
@@ -2264,7 +2278,7 @@ to shrinking the array.
 
 Also the size of an array cannot be changed while it has an active
 bitmap.  If an array has a bitmap, it must be removed before the size
-can be changed. Once the change it complete a new bitmap can be created.
+can be changed. Once the change is complete a new bitmap can be created.
 
 .SS RAID\-DEVICES CHANGES
 
@@ -2440,8 +2454,8 @@ must match one of the names or patterns in a
 line.
 
 .IP +
-Does the device have a valid md superblock.  If a specific metadata
-version is request with
+Does the device have a valid md superblock?  If a specific metadata
+version is requested with
 .B \-\-metadata
 or
 .B \-e
@@ -2472,6 +2486,7 @@ is not able to positively identify the array as belonging to the
 current host, the device will be rejected.
 ..
 
+.PP
 .I mdadm
 keeps a list of arrays that it has partially assembled in
 .B /var/run/mdadm/map
@@ -2644,7 +2659,7 @@ can be started.
 Any devices which are components of /dev/md4 will be marked as faulty
 and then remove from the array.
 
-.B "  mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4
+.B "  mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4"
 .br
 The array
 .B /dev/md4
@@ -2792,7 +2807,7 @@ configuration file at all.
 For further information on mdadm usage, MD and the various levels of
 RAID, see:
 .IP
-.B http://linux\-raid.osdl.org/
+.B http://raid.wiki.kernel.org/
 .PP
 (based upon Jakob \(/Ostergaard's Software\-RAID.HOWTO)
 .\".PP