.B md
supports RAID levels 1 (mirroring) 4 (striped array with parity
device), 5 (striped array with distributed parity information) and 6
-(striped array with distributed dual redundancy information.) If a
+(striped array with distributed dual redundancy information.) If
some number of underlying devices fails while using one of these
levels, the array will continue to function; this number is one for
RAID levels 4 and 5, two for RAID level 6, and all but one (N-1) for
.PP
.B md
also supports a number of pseudo RAID (non-redundant) configurations
-including RAID0 (striped array), LINEAR (catenated array) and
-MULTIPATH (a set of different interfaces to the same device).
+including RAID0 (striped array), LINEAR (catenated array),
+MULTIPATH (a set of different interfaces to the same device),
+and FAULTY (a layer over a single device that sythesises errors).
.SS MD SUPER BLOCK
-With the exception of Legacy Arrays described below, each device that
-is incorporated into an MD array has a
+Though it is possible to create an array without using per-device
+superblocks (see below), each device in an MD array will normally have a
.I super block
written towards the end of the device. This superblock records
information about the structure and state of the array so that the
a 128 bit Universally Unique Identifier that identifies the array that
this device is part of.
-.SS LEGACY ARRAYS
-Early versions of the
-.B md
-driver only supported Linear and Raid0 configurations and so
-did not use an MD superblock (as there is no state that needs to be
-recorded). While it is strongly recommended that all newly created
-arrays utilise a superblock to help ensure that they are assembled
-properly, the
-.B md
-driver still supports legacy linear and raid0 md arrays that
-do not have a superblock.
+.SS NO-SUPERBLOCK ARRAYS
+
+It is possible for some md arrays to be created without a superblock.
+This allows the whole of each device to participate in the array, but
+requires some external mechanism to determine what devices should be
+arranged into which arrays.
+
+FAULTY arrays are an obvious candidate for not having a superblock as
+there is nothing useful to go in the superblock. MUTIPATH arrays can also be
+usefully made without superblocks as there are likely to be other ways
+to detect that two paths connect to the same real devices.
+
+Other array type can work without superblocks are RAID1, RAID0, and LINEAR.
+However these should only be made without a superblock if you are sure
+that you know what you are doing.
.SS LINEAR
One advantage of this arrangement over the more common RAID0
arrangement is that the array may be reconfigured at a later time with
an extra drive and so the array is made bigger without disturbing the
-data that is on the array. However this cannot be done on a live
+data that is on the array. However this cannot yet be done on a live
array.
(paths) to this device, and one of these paths might fail, so there
are some similarities.
-A MULTIPATH array is composed of a number of logical different
+A MULTIPATH array is composed of a number of logically different
devices, often fibre channel interfaces, that all refer the the same
real device. If one of these interfaces fails (e.g. due to cable
-problems), the multipath driver to attempt to redirect requests to
+problems), the multipath driver will attempt to redirect requests to
another interface.
.SS FAULTY
the data in the component device.
The FAULTY module may be requested to simulate faults to allow testing
-of other md levels or of filesystem. Faults can be chosen to trigger
+of other md levels or of filesystems. Faults can be chosen to trigger
on read requests or write requests, and can be transient (a subsequent
read/write at the address will probably succeed) or persistant
(subsequent read/write of the same address will fail). Further, read
request at the same address.
Fault types can be requested with a period. In this case the fault
-will recur repeatedly after the given number of request of the
-relevant time. For example if persistent read faults have a period of
-100, then ever 100th read request would generate a fault, and the
+will recur repeatedly after the given number of requests of the
+relevant type. For example if persistent read faults have a period of
+100, then every 100th read request would generate a fault, and the
faulty sector would be recorded so that subsequent reads on that
sector would also fail.
Faults generated after this limit is exhausted are treated as
transient.
-It list of faulty sectors can be flushed, and the active list of
+The list of faulty sectors can be flushed, and the active list of
failure modes can be cleared.
.SS UNCLEAN SHUTDOWN
When changes are made to a RAID1, RAID4, RAID5 or RAID6 array there is a
possibility of inconsistency for short periods of time as each update
requires are least two block to be written to different devices, and
-these writes probably wont happen at exactly the same time.
+these writes probably won't happen at exactly the same time.
Thus if a system with one of these arrays is shutdown in the middle of
a write operation (e.g. due to power failure), the array may not be
consistent.
"resynchronising" or "resync" is performed in the background. The
array can still be used, though possibly with reduced performance.
+In 2.6 Linux kernels, an md array is marked clean after a short period
+(around 20 milliseconds) of no write activity, and then marked dirty
+before any subsequent write is attempted. This means that unclean
+shutdowns are much less likely with a 2.6 kernel.
+
If a RAID4, RAID5 or RAID6 array is degraded (missing at least one
drive) when it is restarted after an unclean shutdown, it cannot
recalculate parity, and so it is possible that data might be
an MD array, and if any full arrays are found, they are started. This
kernel paramenter 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
.BI md= n , dev , dev ,...
+.TP
+.BI md=d n , dev , dev ,...
This tells the md driver to assemble
.B /dev/md n
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
and
.BR FAULTY .
-.B MULTIPATH is not a Software RAID mechanism, but does involve
+.B MULTIPATH
+is not a Software RAID mechanism, but does involve
multiple devices. For
.B MULTIPATH
each device is a path to one common physical storage device.
-.B FAULTY is also no true RAID, and it only involves one device. It
+.B FAULTY
+is also not true RAID, and it only involves one device. It
provides a layer over a true device that can be used to inject faults.
-.B mdadm
-is a program that can be used to create, manage, and monitor
-MD devices. As
-such it provides a similar set of functionality to the
-.B raidtools
-packages.
-The key differences between
-.B mdadm
-and
-.B raidtools
-are:
-.IP \(bu 4
-.B mdadm
-is a single program and not a collection of programs.
-.IP \(bu 4
-.B mdadm
-can perform (almost) all of its functions without having a
-configuration file and does not use one by default. Also
-.B mdadm
-helps with management of the configuration
-file.
-.IP \(bu 4
-.B mdadm
-can provide information about your arrays (through Query, Detail, and Examine)
-that
-.B raidtools
-cannot.
-.P
-.I mdadm
-does not use
-.IR /etc/raidtab ,
-the
-.B raidtools
-configuration file, at all. It has a different configuration file
-with a different format and an different purpose.
+'''.B mdadm
+'''is a program that can be used to create, manage, and monitor
+'''MD devices. As
+'''such it provides a similar set of functionality to the
+'''.B raidtools
+'''packages.
+'''The key differences between
+'''.B mdadm
+'''and
+'''.B raidtools
+'''are:
+'''.IP \(bu 4
+'''.B mdadm
+'''is a single program and not a collection of programs.
+'''.IP \(bu 4
+'''.B mdadm
+'''can perform (almost) all of its functions without having a
+'''configuration file and does not use one by default. Also
+'''.B mdadm
+'''helps with management of the configuration
+'''file.
+'''.IP \(bu 4
+'''.B mdadm
+'''can provide information about your arrays (through Query, Detail, and Examine)
+'''that
+'''.B raidtools
+'''cannot.
+'''.P
+'''.I mdadm
+'''does not use
+'''.IR /etc/raidtab ,
+'''the
+'''.B raidtools
+'''configuration file, at all. It has a different configuration file
+'''with a different format and an different purpose.
.SH MODES
mdadm has 7 major modes of operation:
.TP
.B Build
-Build a legacy array without per-device superblocks.
+Build an array that doesn't have per-device superblocks. For these
+sorts of arrays,
+.I mdadm
+cannot differentiate between initial creation and subsequent assembly
+of an array. It also cannot perform any checks that appropriate
+devices have been requested. Because of this, the
+.B Build
+mode should only be used together with a complete understanding of
+what you are doing.
.TP
.B Create
.TP
.BR -h ", " --help
-Display help message or, after above option, mode specific help
-message.
+Display general help message or, after one of the above options, a
+mode specific help message.
.TP
.B --help-options
.BR -v ", " --verbose
Be more verbose about what is happening. This can be used twice to be
extra-verbose.
-This currently only affects
+The extra verbosity currently only affects
.B --detail --scan
and
.BR "--examine --scan" .
When used with
.IR --build ,
-only linear, raid0, 0, stripe are valid.
+only linear, stripe, raid0, 0, raid1, multipath, mp, and faulty are valid.
.TP
.BR -p ", " --parity=
.BR --grow .
The size can be given as
.B max
-which means to choose the largest size that fits all on all current drives.
+which means to choose the largest size that fits on all current drives.
.TP
.BR --assume-clean
'standard' format, and the type and minor number will be determined
from this. See DEVICE NAMES below.
-The argumentment can also come immediately after
+The argument can also come immediately after
"-a". e.g. "-ap".
If
If the md device name is in a 'standard' format as described in DEVICE
NAMES, then it will be created, if necessary, with the appropriate
number based on that name. If the device name is not in one of these
-formats, then a unused minor number will be allocted. The minor
+formats, then a unused minor number will be allocated. The minor
number will be considered unused if there is no active array for that
number, and there is no entry in /dev for that number and with a
non-standard name.
.TP
.B --sparc2.2
-In an array was created on a 2.2 Linux kernel patched with RAID
+If an array was created on a 2.2 Linux kernel patched with RAID
support, the superblock will have been created incorrectly, or at
least incompatibly with 2.4 and later kernels. Using the
.B --sparc2.2
.B NewArray
events and more significantly
.B DegradedArray
+and
+.B SparesMissing
events. Running
.in +5
.B " mdadm --monitor --scan -1"
.B TestMessage
alert for every array found at startup. This alert gets mailed and
passed to the alert program. This can be used for testing that alert
-message to get through successfully.
+message do get through successfully.
.SH ASSEMBLE MODE
files for the first 4 partitions are also created. If a different
number is required it can be simply appended to the auto option.
e.g. "auto=part8". Partition names are created by appending a digit
-string to the device name, with an intervening "_p" if the device name
+string to the device name, with an intervening "p" if the device name
ends with a digit.
The
.PP
This usage is similar to
.BR --create .
-The difference is that it creates a legacy array without a superblock. With
+The difference is that it creates an array without a superblock. With
these arrays there is no difference between initially creating the array and
subsequently assembling the array, except that hopefully there is useful
data there in the second case.
-The level may only be 0, raid0, or linear. All devices must be listed
-and the array will be started once complete.
+The level may raid0, linear, multipath, or faulty, or one of their
+synonyms. All devices must be listed and the array will be started
+once complete.
.SH CREATE MODE
This usage will initialise a new md array, associate some devices with
it, and activate the array.
-This the
+If the
.B --auto
option is given (as described in more detail in the section on
Assemble mode), then the md device will be created with a suitable
may move a spare drive from one array to another if they are in the
same
.B spare-group
-and if the destination array has a failed drive but not spares.
+and if the destination array has a failed drive but no spares.
If any devices are listed on the command line,
.B mdadm
for arrays with redundancy, and the raid-disks attribute of RAID1
arrays.
-Normally when an array is build the "size" it taken from the smallest
+Normally when an array is built the "size" it taken from the smallest
of the drives. If all the small drives in an arrays are, one at a
time, removed and replaced with larger drives, then you could have an
array of large drives with only a small amount used. In this
devices that which were in those slots must be failed and removed.
When the number of devices is increased, any hot spares that are
-present may be activated immediately.
+present will be activated immediately.
.SH EXAMPLES
.B mdadm
was previously known as
.BR mdctl .
-
+.P
+.B mdadm
+is completely separate from the
+.B raidtools
+package, and does not use the
+.I /etc/raidtab
+configuration file at all.
+
.SH SEE ALSO
For information on the various levels of
RAID, check out:
.UR http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
.UE
+'''.PP
+'''for new releases of the RAID driver check out:
+'''
+'''.IP
+'''.UR ftp://ftp.kernel.org/pub/linux/kernel/people/mingo/raid-patches
+'''ftp://ftp.kernel.org/pub/linux/kernel/people/mingo/raid-patches
+'''.UE
+'''.PP
+'''or
+'''.IP
+'''.UR http://www.cse.unsw.edu.au/~neilb/patches/linux-stable/
+'''http://www.cse.unsw.edu.au/~neilb/patches/linux-stable/
+'''.UE
.PP
-for new releases of the RAID driver check out:
-
+The lastest version of
+.I mdadm
+should always be available from
.IP
-.UR ftp://ftp.kernel.org/pub/linux/kernel/people/mingo/raid-patches
-ftp://ftp.kernel.org/pub/linux/kernel/people/mingo/raid-patches
+.UR http://www.kernel.org/pub/linux/utils/raid/mdadm/
+http://www.kernel.org/pub/linux/utils/raid/mdadm/
.UE
.PP
-or
-.IP
-.UR http://www.cse.unsw.edu.au/~neilb/patches/linux-stable/
-http://www.cse.unsw.edu.au/~neilb/patches/linux-stable/
-.URk
-.PP
-.BR mdadm.conf (5),
-.BR md (4).
+.IR mdadm.conf (5),
+.IR md (4).
.PP
.IR raidtab (5),
.IR raid0run (8),
.IR raidstop (8),
-.IR mkraid (8)
+.IR mkraid (8).
projects / thirdparty / mdadm.git / commitdiff
