]> git.ipfire.org Git - thirdparty/mdadm.git/blobdiff - mdmon.8
sysfs: Use the presence of /sys/block/<dev>/md as indicator of valid device
[thirdparty/mdadm.git] / mdmon.8
diff --git a/mdmon.8 b/mdmon.8
index efa30898635cf1889b3976543273b846f46b6d9e..ac7352fc5822bdb4a87e71eee3e9ef8288876d26 100644 (file)
--- a/mdmon.8
+++ b/mdmon.8
@@ -1,11 +1,11 @@
 .\" See file COPYING in distribution for details.
 .\" See file COPYING in distribution for details.
-.TH MDMON 8 "" v3.2-devel
+.TH MDMON 8 "" v4.0
 .SH NAME
 mdmon \- monitor MD external metadata arrays
 
 .SH SYNOPSIS
 
 .SH NAME
 mdmon \- monitor MD external metadata arrays
 
 .SH SYNOPSIS
 
-.BI mdmon " [--all] [--takeover] CONTAINER"
+.BI mdmon " [--all] [--takeover] [--foreground] CONTAINER"
 
 .SH OVERVIEW
 The 2.6.27 kernel brings the ability to support external metadata arrays.
 
 .SH OVERVIEW
 The 2.6.27 kernel brings the ability to support external metadata arrays.
@@ -101,10 +101,10 @@ call is still required.
 External metadata formats, like DDF, differ from the native MD metadata
 formats in that they define a set of disks and a series of sub-arrays
 within those disks.  MD metadata in comparison defines a 1:1
 External metadata formats, like DDF, differ from the native MD metadata
 formats in that they define a set of disks and a series of sub-arrays
 within those disks.  MD metadata in comparison defines a 1:1
-relationship between a set of block devices and a raid array.  For
-example to create 2 arrays at different raid levels on a single
+relationship between a set of block devices and a RAID array.  For
+example to create 2 arrays at different RAID levels on a single
 set of disks, MD metadata requires the disks be partitioned and then
 set of disks, MD metadata requires the disks be partitioned and then
-each array can created be created with a subset of those partitions.  The
+each array can be created with a subset of those partitions.  The
 supported external formats perform this disk carving internally.
 .P
 Container devices simply hold references to all member disks and allow
 supported external formats perform this disk carving internally.
 .P
 Container devices simply hold references to all member disks and allow
@@ -131,6 +131,14 @@ The
 device to monitor.  It can be a full path like /dev/md/container, or a
 simple md device name like md127.
 .TP
 device to monitor.  It can be a full path like /dev/md/container, or a
 simple md device name like md127.
 .TP
+.B \-\-foreground
+Normally,
+.I mdmon
+will fork and continue in the background.  Adding this option will
+skip that step and run
+.I mdmon
+in the foreground.
+.TP
 .B \-\-takeover
 This instructs
 .I mdmon
 .B \-\-takeover
 This instructs
 .I mdmon
@@ -165,6 +173,7 @@ argument is over-written with the name of the container.  To allow for
 containers with names longer than 5 characters, this argument can be
 arbitrarily extended, e.g. to
 .BR \-\-all-active-arrays .
 containers with names longer than 5 characters, this argument can be
 arbitrarily extended, e.g. to
 .BR \-\-all-active-arrays .
+.TP
 
 .PP
 Note that
 
 .PP
 Note that
@@ -172,7 +181,7 @@ Note that
 is automatically started by
 .I mdadm
 when needed and so does not need to be considered when working with
 is automatically started by
 .I mdadm
 when needed and so does not need to be considered when working with
-RAID arrays.  The only times it is run other that by
+RAID arrays.  The only times it is run other than by
 .I  mdadm
 is when the boot scripts need to restart it after mounting the new
 root filesystem.
 .I  mdadm
 is when the boot scripts need to restart it after mounting the new
 root filesystem.
@@ -208,7 +217,7 @@ and
 .B .sock
 file.  The particular filesystem to use is given to mdmon at compile
 time and defaults to
 .B .sock
 file.  The particular filesystem to use is given to mdmon at compile
 time and defaults to
-.BR /dev/.mdadm .
+.BR /run/mdadm .
 
 This filesystem must persist through to shutdown time.
 
 
 This filesystem must persist through to shutdown time.