]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | Tools that manage md devices can be found at |
2 | http://www.<country>.kernel.org/pub/linux/utils/raid/.... | |
3 | ||
4 | ||
5 | Boot time assembly of RAID arrays | |
6 | --------------------------------- | |
7 | ||
8 | You can boot with your md device with the following kernel command | |
9 | lines: | |
10 | ||
11 | for old raid arrays without persistent superblocks: | |
12 | md=<md device no.>,<raid level>,<chunk size factor>,<fault level>,dev0,dev1,...,devn | |
13 | ||
14 | for raid arrays with persistent superblocks | |
15 | md=<md device no.>,dev0,dev1,...,devn | |
16 | or, to assemble a partitionable array: | |
17 | md=d<md device no.>,dev0,dev1,...,devn | |
18 | ||
19 | md device no. = the number of the md device ... | |
20 | 0 means md0, | |
21 | 1 md1, | |
22 | 2 md2, | |
23 | 3 md3, | |
24 | 4 md4 | |
25 | ||
26 | raid level = -1 linear mode | |
27 | 0 striped mode | |
28 | other modes are only supported with persistent super blocks | |
29 | ||
30 | chunk size factor = (raid-0 and raid-1 only) | |
31 | Set the chunk size as 4k << n. | |
32 | ||
33 | fault level = totally ignored | |
34 | ||
35 | dev0-devn: e.g. /dev/hda1,/dev/hdc1,/dev/sda1,/dev/sdb1 | |
36 | ||
37 | A possible loadlin line (Harald Hoyer <HarryH@Royal.Net>) looks like this: | |
38 | ||
39 | e:\loadlin\loadlin e:\zimage root=/dev/md0 md=0,0,4,0,/dev/hdb2,/dev/hdc3 ro | |
40 | ||
41 | ||
42 | Boot time autodetection of RAID arrays | |
43 | -------------------------------------- | |
44 | ||
45 | When md is compiled into the kernel (not as module), partitions of | |
46 | type 0xfd are scanned and automatically assembled into RAID arrays. | |
47 | This autodetection may be suppressed with the kernel parameter | |
48 | "raid=noautodetect". As of kernel 2.6.9, only drives with a type 0 | |
49 | superblock can be autodetected and run at boot time. | |
50 | ||
51 | The kernel parameter "raid=partitionable" (or "raid=part") means | |
52 | that all auto-detected arrays are assembled as partitionable. | |
53 | ||
54 | ||
55 | Superblock formats | |
56 | ------------------ | |
57 | ||
58 | The md driver can support a variety of different superblock formats. | |
59 | Currently, it supports superblock formats "0.90.0" and the "md-1" format | |
60 | introduced in the 2.5 development series. | |
61 | ||
62 | The kernel will autodetect which format superblock is being used. | |
63 | ||
64 | Superblock format '0' is treated differently to others for legacy | |
65 | reasons - it is the original superblock format. | |
66 | ||
67 | ||
68 | General Rules - apply for all superblock formats | |
69 | ------------------------------------------------ | |
70 | ||
71 | An array is 'created' by writing appropriate superblocks to all | |
72 | devices. | |
73 | ||
74 | It is 'assembled' by associating each of these devices with an | |
75 | particular md virtual device. Once it is completely assembled, it can | |
76 | be accessed. | |
77 | ||
78 | An array should be created by a user-space tool. This will write | |
79 | superblocks to all devices. It will usually mark the array as | |
80 | 'unclean', or with some devices missing so that the kernel md driver | |
81 | can create appropriate redundancy (copying in raid1, parity | |
82 | calculation in raid4/5). | |
83 | ||
84 | When an array is assembled, it is first initialized with the | |
85 | SET_ARRAY_INFO ioctl. This contains, in particular, a major and minor | |
86 | version number. The major version number selects which superblock | |
87 | format is to be used. The minor number might be used to tune handling | |
88 | of the format, such as suggesting where on each device to look for the | |
89 | superblock. | |
90 | ||
91 | Then each device is added using the ADD_NEW_DISK ioctl. This | |
92 | provides, in particular, a major and minor number identifying the | |
93 | device to add. | |
94 | ||
95 | The array is started with the RUN_ARRAY ioctl. | |
96 | ||
97 | Once started, new devices can be added. They should have an | |
98 | appropriate superblock written to them, and then passed be in with | |
99 | ADD_NEW_DISK. | |
100 | ||
101 | Devices that have failed or are not yet active can be detached from an | |
102 | array using HOT_REMOVE_DISK. | |
103 | ||
104 | ||
105 | Specific Rules that apply to format-0 super block arrays, and | |
106 | arrays with no superblock (non-persistent). | |
107 | ------------------------------------------------------------- | |
108 | ||
109 | An array can be 'created' by describing the array (level, chunksize | |
110 | etc) in a SET_ARRAY_INFO ioctl. This must has major_version==0 and | |
111 | raid_disks != 0. | |
112 | ||
113 | Then uninitialized devices can be added with ADD_NEW_DISK. The | |
114 | structure passed to ADD_NEW_DISK must specify the state of the device | |
115 | and it's role in the array. | |
116 | ||
117 | Once started with RUN_ARRAY, uninitialized spares can be added with | |
118 | HOT_ADD_DISK. |