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