]>
Commit | Line | Data |
---|---|---|
222a7bfd N |
1 | Subject: ANNOUNCE: mdadm 3.0-rc1 - A tool for managing Soft RAID under Linux |
2 | ||
3 | I am pleased to announce the availability of | |
4 | mdadm version 3.0-rc1 | |
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 | ||
13 | This is a "release candidate" which means that I think it is safe | |
14 | to use and that there will be no significant change in functionality | |
15 | before release. | |
16 | ||
17 | The man pages aren't really "release candidate" yet but I will be | |
18 | working on them before the final release. | |
19 | ||
20 | The most significant changes since -devel3 relate to the names of md | |
21 | devices as they appear in /dev and /dev/md/, and in particular the names | |
22 | that are used when an array is assembled with "--incremental" or with | |
23 | "mdadm --assemble --scan" when there are no ARRAY lines in mdadm.conf. | |
24 | In these cases mdadm needs to deduce a name to use, and to try to | |
25 | avoid using a name that a different array might have a stronger claim to. | |
26 | The rules are: | |
27 | - if the array is mentioned in mdadm.conf, use the name given there. | |
28 | - if the array appear to have been created for "this host" using the | |
29 | "homehost" concept, trust the name given in the metadata | |
30 | - if the new setting "HOMEHOST <ignore>" is given (can be in mdadm.conf | |
31 | or on command line) the the name given in the metadata is not | |
32 | associated with some other array by mdadm.conf, then trust the | |
33 | name given in the metadata | |
34 | - otherwise use the name in the metadata, but in an untrusted manner. | |
35 | ||
36 | If a name is untrusted, or if the name is already in use by another | |
37 | array, then a numeric suffix like "_0", "_1" is appended to create | |
38 | a unique name for the array. | |
39 | ||
40 | That name is then used to create a device file in /dev/md/. | |
41 | ||
42 | So if all arrays needed for boot will always be listed in | |
43 | /etc/mdadm.conf, then it is appropriate to add "HOMEHOST <ignore>" to | |
44 | mdadm.conf and there is no risk of conflicting names. However if you | |
45 | want auto-assemble to assemble all arrays at boot time and you don't | |
46 | want to list them in mdadm.conf, then don't give "HOMEHOST <ignore>" | |
47 | either else there could be a risk of the wrong array being assembled | |
48 | for a given name. | |
49 | ||
50 | ||
51 | ||
52 | The following is the same introduction to 3.x as appeared in | |
53 | previous announcements. | |
54 | ||
55 | Any testing and feedback will be greatly appreciated. | |
56 | ||
57 | NeilBrown 11th May 2009 | |
58 | ||
59 | ||
60 | ===================================================== | |
61 | ||
62 | The significant change which justifies the new major version number is | |
63 | that mdadm can now handle metadata updates entirely in userspace. | |
64 | This allows mdadm to support metadata formats that the kernel knows | |
65 | nothing about. | |
66 | ||
67 | Currently two such metadata formats are supported: | |
68 | - DDF - The SNIA standard format | |
69 | - Intel Matrix - The metadata used by recent Intel ICH controlers. | |
70 | ||
71 | Also the approach to device names has changed significantly. | |
72 | ||
73 | If udev is installed on the system, mdadm will not create any devices | |
74 | in /dev. Rather it allows udev to manage those devices. For this to work | |
75 | as expected, the included udev rules file should be installed. | |
76 | ||
77 | If udev is not install, mdadm will still create devices and symlinks | |
78 | as required, and will also remove them when the array is stopped. | |
79 | ||
80 | mdadm now requires all devices which do not have a standard name (mdX | |
81 | or md_dX) to live in the directory /dev/md/. Names in this directory | |
82 | will always be created as symlinks back to the standard name in /dev. | |
83 | ||
84 | The man pages contain some information about the new externally managed | |
85 | metadata. However see below for a more condensed overview. | |
86 | ||
87 | Externally managed metadata introduces the concept of a 'container'. | |
88 | A container is a collection of (normally) physical devices which have | |
89 | a common set of metadata. A container is assembled as an md array, but | |
90 | is left 'inactive'. | |
91 | ||
92 | A container can contain one or more data arrays. These are composed from | |
93 | slices (partitions?) of various devices in the container. | |
94 | ||
95 | For example, a 5 devices DDF set can container a RAID1 using the first | |
96 | half of two devices, a RAID0 using the first half of the remain 3 devices, | |
97 | and a RAID5 over thte second half of all 5 devices. | |
98 | ||
99 | A container can be created with | |
100 | ||
101 | mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde] | |
102 | ||
103 | or "-e imsm" to use the Intel Matrix Storage Manager. | |
104 | ||
105 | An array can be created within a container either by giving the | |
106 | container name and the only member: | |
107 | ||
108 | mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0 | |
109 | ||
110 | or by listing the component devices | |
111 | ||
112 | mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde] | |
113 | ||
114 | To assemble a container, it is easiest just to pass each device in turn to | |
115 | mdadm -I | |
116 | ||
117 | for i in /dev/sd[abcde] | |
118 | do mdadm -I $i | |
119 | done | |
120 | ||
121 | This will assemble the container and the components. | |
122 | ||
123 | Alternately the container can be assembled explicitly | |
124 | ||
125 | mdadm -A /dev/md0 /dev/sd[abcde] | |
126 | ||
127 | Then the components can all be assembled with | |
128 | ||
129 | mdadm -I /dev/md0 | |
130 | ||
131 | For each container, mdadm will start a program called "mdmon" which will | |
132 | monitor the array and effect any metadata updates needed. The array is | |
133 | initially assembled readonly. It is up to "mdmon" to mark the metadata | |
134 | as 'dirty' and which the array to 'read-write'. | |
135 | ||
136 | The version 0.90 and 1.x metadata formats supported by previous | |
137 | versions for mdadm are still supported and the kernel still performs | |
138 | the same updates it use to. The new 'mdmon' approach is only used for | |
139 | newly introduced metadata types. |