]> git.ipfire.org Git - thirdparty/mdadm.git/blame - ANNOUNCE-3.0
Correctly abort level change when reshape_array fails.
[thirdparty/mdadm.git] / ANNOUNCE-3.0
CommitLineData
6e92d480 1Subject: ANNOUNCE: mdadm 3.0 - A tool for managing Soft RAID under Linux
1679bef2 2
6e92d480
N
3I am pleased to (finally) announce the availability of
4 mdadm version 3.0
1679bef2
N
5
6It is available at the usual places:
7 countrycode=xx.
8 http://www.${countrycode}kernel.org/pub/linux/utils/raid/mdadm/
9and via git at
10 git://neil.brown.name/mdadm
11 http://neil.brown.name/git?p=mdadm
12
6e92d480
N
13
14This is a major new version and as such should be treated with some
15caution. However it has seen substantial testing and is considerred
16to be ready for wide use.
17
1679bef2
N
18
19The significant change which justifies the new major version number is
20that mdadm can now handle metadata updates entirely in userspace.
21This allows mdadm to support metadata formats that the kernel knows
22nothing about.
23
24Currently two such metadata formats are supported:
25 - DDF - The SNIA standard format
26 - Intel Matrix - The metadata used by recent Intel ICH controlers.
27
28Also the approach to device names has changed significantly.
29
30If udev is installed on the system, mdadm will not create any devices
31in /dev. Rather it allows udev to manage those devices. For this to work
32as expected, the included udev rules file should be installed.
33
6e92d480 34If udev is not installed, mdadm will still create devices and symlinks
1679bef2
N
35as required, and will also remove them when the array is stopped.
36
37mdadm now requires all devices which do not have a standard name (mdX
38or md_dX) to live in the directory /dev/md/. Names in this directory
39will always be created as symlinks back to the standard name in /dev.
40
41The man pages contain some information about the new externally managed
42metadata. However see below for a more condensed overview.
43
44Externally managed metadata introduces the concept of a 'container'.
45A container is a collection of (normally) physical devices which have
46a common set of metadata. A container is assembled as an md array, but
47is left 'inactive'.
48
49A container can contain one or more data arrays. These are composed from
50slices (partitions?) of various devices in the container.
51
52For example, a 5 devices DDF set can container a RAID1 using the first
53half of two devices, a RAID0 using the first half of the remain 3 devices,
54and a RAID5 over thte second half of all 5 devices.
55
56A container can be created with
57
58 mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]
59
60or "-e imsm" to use the Intel Matrix Storage Manager.
61
62An array can be created within a container either by giving the
63container name and the only member:
64
65 mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0
66
67or by listing the component devices
68
69 mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]
70
71To assemble a container, it is easiest just to pass each device in turn to
72mdadm -I
73
74 for i in /dev/sd[abcde]
75 do mdadm -I $i
76 done
77
78This will assemble the container and the components.
79
80Alternately the container can be assembled explicitly
81
82 mdadm -A /dev/md0 /dev/sd[abcde]
83
84Then the components can all be assembled with
85
86 mdadm -I /dev/md0
87
88For each container, mdadm will start a program called "mdmon" which will
89monitor the array and effect any metadata updates needed. The array is
90initially assembled readonly. It is up to "mdmon" to mark the metadata
91as 'dirty' and which the array to 'read-write'.
92
93The version 0.90 and 1.x metadata formats supported by previous
94versions for mdadm are still supported and the kernel still performs
95the same updates it use to. The new 'mdmon' approach is only used for
96newly introduced metadata types.
97
6e92d480 98NeilBrown 2nd June 2009