]> git.ipfire.org Git - thirdparty/mdadm.git/blame - ANNOUNCE-3.0-devel3
imsm: kill "auto=" in brief_examine_super_imsm
[thirdparty/mdadm.git] / ANNOUNCE-3.0-devel3
CommitLineData
b9d77223
N
1Subject: ANNOUNCE: mdadm 3.0-devel3 - A tool for managing Soft RAID under Linux
2
3I am pleased to announce the availability of
4 mdadm version 3.0-devel3
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
13Note that this is a "devel" release. It should be used with
14caution, though it is believed to be close to release-candidate stage.
15
16There have been numerous improvements and additions since -devel2.
17I think we are close to a release of 3.0.
18
19I need to add lots of tests to the test suite to test the new
20functionality. And I need to review the man pages.
21
22After that I will release -rc1 followed by -final.
23
24
25The following is the same introduction to 3.x as appeared in
26previous announcements.
27
28
29Any testing and feedback will be greatly appreciated.
30
31NeilBrown 10th March 2009
32
33
34=====================================================
35
36The significant change which justifies the new major version number is
37that mdadm can now handle metadata updates entirely in userspace.
38This allows mdadm to support metadata formats that the kernel knows
39nothing about.
40
41Currently two such metadata formats are supported:
42 - DDF - The SNIA standard format
43 - Intel Matrix - The metadata used by recent Intel ICH controlers.
44
45Also the approach to device names has changed significantly.
46
47If udev is installed on the system, mdadm will not create any devices
48in /dev. Rather it allows udev to manage those devices. For this to work
49as expected, the included udev rules file should be installed.
50
51If udev is not install, mdadm will still create devices and symlinks
52as required, and will also remove them when the array is stopped.
53
54mdadm now requires all devices which do not have a standard name (mdX
55or md_dX) to live in the directory /dev/md/. Names in this directory
56will always be created as symlinks back to the standard name in /dev.
57
58The man pages contain some information about the new externally managed
59metadata. However see below for a more condensed overview.
60
61Externally managed metadata introduces the concept of a 'container'.
62A container is a collection of (normally) physical devices which have
63a common set of metadata. A container is assembled as an md array, but
64is left 'inactive'.
65
66A container can contain one or more data arrays. These are composed from
67slices (partitions?) of various devices in the container.
68
69For example, a 5 devices DDF set can container a RAID1 using the first
70half of two devices, a RAID0 using the first half of the remain 3 devices,
71and a RAID5 over thte second half of all 5 devices.
72
73A container can be created with
74
75 mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]
76
77or "-e imsm" to use the Intel Matrix Storage Manager.
78
79An array can be created within a container either by giving the
80container name and the only member:
81
82 mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0
83
84or by listing the component devices
85
86 mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]
87
88To assemble a container, it is easiest just to pass each device in turn to
89mdadm -I
90
91 for i in /dev/sd[abcde]
92 do mdadm -I $i
93 done
94
95This will assemble the container and the components.
96
97Alternately the container can be assembled explicitly
98
99 mdadm -A /dev/md0 /dev/sd[abcde]
100
101Then the components can all be assembled with
102
103 mdadm -I /dev/md0
104
105For each container, mdadm will start a program called "mdmon" which will
106monitor the array and effect any metadata updates needed. The array is
107initially assembled readonly. It is up to "mdmon" to mark the metadata
108as 'dirty' and which the array to 'read-write'.
109
110The version 0.90 and 1.x metadata formats supported by previous
111versions for mdadm are still supported and the kernel still performs
112the same updates it use to. The new 'mdmon' approach is only used for
113newly introduced metadata types.