diff options
Diffstat (limited to 'Documentation/md.txt')
-rw-r--r-- | Documentation/md.txt | 120 |
1 files changed, 120 insertions, 0 deletions
diff --git a/Documentation/md.txt b/Documentation/md.txt index 23e6cce40f9c..03a13c462cf2 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -51,6 +51,30 @@ superblock can be autodetected and run at boot time. | |||
51 | The kernel parameter "raid=partitionable" (or "raid=part") means | 51 | The kernel parameter "raid=partitionable" (or "raid=part") means |
52 | that all auto-detected arrays are assembled as partitionable. | 52 | that all auto-detected arrays are assembled as partitionable. |
53 | 53 | ||
54 | Boot time assembly of degraded/dirty arrays | ||
55 | ------------------------------------------- | ||
56 | |||
57 | If a raid5 or raid6 array is both dirty and degraded, it could have | ||
58 | undetectable data corruption. This is because the fact that it is | ||
59 | 'dirty' means that the parity cannot be trusted, and the fact that it | ||
60 | is degraded means that some datablocks are missing and cannot reliably | ||
61 | be reconstructed (due to no parity). | ||
62 | |||
63 | For this reason, md will normally refuse to start such an array. This | ||
64 | requires the sysadmin to take action to explicitly start the array | ||
65 | desipite possible corruption. This is normally done with | ||
66 | mdadm --assemble --force .... | ||
67 | |||
68 | This option is not really available if the array has the root | ||
69 | filesystem on it. In order to support this booting from such an | ||
70 | array, md supports a module parameter "start_dirty_degraded" which, | ||
71 | when set to 1, bypassed the checks and will allows dirty degraded | ||
72 | arrays to be started. | ||
73 | |||
74 | So, to boot with a root filesystem of a dirty degraded raid[56], use | ||
75 | |||
76 | md-mod.start_dirty_degraded=1 | ||
77 | |||
54 | 78 | ||
55 | Superblock formats | 79 | Superblock formats |
56 | ------------------ | 80 | ------------------ |
@@ -141,6 +165,70 @@ All md devices contain: | |||
141 | in a fully functional array. If this is not yet known, the file | 165 | in a fully functional array. If this is not yet known, the file |
142 | will be empty. If an array is being resized (not currently | 166 | will be empty. If an array is being resized (not currently |
143 | possible) this will contain the larger of the old and new sizes. | 167 | possible) this will contain the larger of the old and new sizes. |
168 | Some raid level (RAID1) allow this value to be set while the | ||
169 | array is active. This will reconfigure the array. Otherwise | ||
170 | it can only be set while assembling an array. | ||
171 | |||
172 | chunk_size | ||
173 | This is the size if bytes for 'chunks' and is only relevant to | ||
174 | raid levels that involve striping (1,4,5,6,10). The address space | ||
175 | of the array is conceptually divided into chunks and consecutive | ||
176 | chunks are striped onto neighbouring devices. | ||
177 | The size should be atleast PAGE_SIZE (4k) and should be a power | ||
178 | of 2. This can only be set while assembling an array | ||
179 | |||
180 | component_size | ||
181 | For arrays with data redundancy (i.e. not raid0, linear, faulty, | ||
182 | multipath), all components must be the same size - or at least | ||
183 | there must a size that they all provide space for. This is a key | ||
184 | part or the geometry of the array. It is measured in sectors | ||
185 | and can be read from here. Writing to this value may resize | ||
186 | the array if the personality supports it (raid1, raid5, raid6), | ||
187 | and if the component drives are large enough. | ||
188 | |||
189 | metadata_version | ||
190 | This indicates the format that is being used to record metadata | ||
191 | about the array. It can be 0.90 (traditional format), 1.0, 1.1, | ||
192 | 1.2 (newer format in varying locations) or "none" indicating that | ||
193 | the kernel isn't managing metadata at all. | ||
194 | |||
195 | level | ||
196 | The raid 'level' for this array. The name will often (but not | ||
197 | always) be the same as the name of the module that implements the | ||
198 | level. To be auto-loaded the module must have an alias | ||
199 | md-$LEVEL e.g. md-raid5 | ||
200 | This can be written only while the array is being assembled, not | ||
201 | after it is started. | ||
202 | |||
203 | new_dev | ||
204 | This file can be written but not read. The value written should | ||
205 | be a block device number as major:minor. e.g. 8:0 | ||
206 | This will cause that device to be attached to the array, if it is | ||
207 | available. It will then appear at md/dev-XXX (depending on the | ||
208 | name of the device) and further configuration is then possible. | ||
209 | |||
210 | sync_speed_min | ||
211 | sync_speed_max | ||
212 | This are similar to /proc/sys/dev/raid/speed_limit_{min,max} | ||
213 | however they only apply to the particular array. | ||
214 | If no value has been written to these, of if the word 'system' | ||
215 | is written, then the system-wide value is used. If a value, | ||
216 | in kibibytes-per-second is written, then it is used. | ||
217 | When the files are read, they show the currently active value | ||
218 | followed by "(local)" or "(system)" depending on whether it is | ||
219 | a locally set or system-wide value. | ||
220 | |||
221 | sync_completed | ||
222 | This shows the number of sectors that have been completed of | ||
223 | whatever the current sync_action is, followed by the number of | ||
224 | sectors in total that could need to be processed. The two | ||
225 | numbers are separated by a '/' thus effectively showing one | ||
226 | value, a fraction of the process that is complete. | ||
227 | |||
228 | sync_speed | ||
229 | This shows the current actual speed, in K/sec, of the current | ||
230 | sync_action. It is averaged over the last 30 seconds. | ||
231 | |||
144 | 232 | ||
145 | As component devices are added to an md array, they appear in the 'md' | 233 | As component devices are added to an md array, they appear in the 'md' |
146 | directory as new directories named | 234 | directory as new directories named |
@@ -167,6 +255,38 @@ Each directory contains: | |||
167 | of being recoverred to | 255 | of being recoverred to |
168 | This list make grow in future. | 256 | This list make grow in future. |
169 | 257 | ||
258 | errors | ||
259 | An approximate count of read errors that have been detected on | ||
260 | this device but have not caused the device to be evicted from | ||
261 | the array (either because they were corrected or because they | ||
262 | happened while the array was read-only). When using version-1 | ||
263 | metadata, this value persists across restarts of the array. | ||
264 | |||
265 | This value can be written while assembling an array thus | ||
266 | providing an ongoing count for arrays with metadata managed by | ||
267 | userspace. | ||
268 | |||
269 | slot | ||
270 | This gives the role that the device has in the array. It will | ||
271 | either be 'none' if the device is not active in the array | ||
272 | (i.e. is a spare or has failed) or an integer less than the | ||
273 | 'raid_disks' number for the array indicating which possition | ||
274 | it currently fills. This can only be set while assembling an | ||
275 | array. A device for which this is set is assumed to be working. | ||
276 | |||
277 | offset | ||
278 | This gives the location in the device (in sectors from the | ||
279 | start) where data from the array will be stored. Any part of | ||
280 | the device before this offset us not touched, unless it is | ||
281 | used for storing metadata (Formats 1.1 and 1.2). | ||
282 | |||
283 | size | ||
284 | The amount of the device, after the offset, that can be used | ||
285 | for storage of data. This will normally be the same as the | ||
286 | component_size. This can be written while assembling an | ||
287 | array. If a value less than the current component_size is | ||
288 | written, component_size will be reduced to this value. | ||
289 | |||
170 | 290 | ||
171 | An active md device will also contain and entry for each active device | 291 | An active md device will also contain and entry for each active device |
172 | in the array. These are named | 292 | in the array. These are named |