Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 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 | |
NeilBrown | 6ff8d8ec | 2006-01-06 00:20:15 -0800 | [diff] [blame] | 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 |
Matt LaPlante | fff9289 | 2006-10-03 22:47:42 +0200 | [diff] [blame] | 65 | despite possible corruption. This is normally done with |
NeilBrown | 6ff8d8ec | 2006-01-06 00:20:15 -0800 | [diff] [blame] | 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 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 78 | |
| 79 | Superblock formats |
| 80 | ------------------ |
| 81 | |
| 82 | The md driver can support a variety of different superblock formats. |
| 83 | Currently, it supports superblock formats "0.90.0" and the "md-1" format |
| 84 | introduced in the 2.5 development series. |
| 85 | |
| 86 | The kernel will autodetect which format superblock is being used. |
| 87 | |
| 88 | Superblock format '0' is treated differently to others for legacy |
| 89 | reasons - it is the original superblock format. |
| 90 | |
| 91 | |
| 92 | General Rules - apply for all superblock formats |
| 93 | ------------------------------------------------ |
| 94 | |
| 95 | An array is 'created' by writing appropriate superblocks to all |
| 96 | devices. |
| 97 | |
| 98 | It is 'assembled' by associating each of these devices with an |
| 99 | particular md virtual device. Once it is completely assembled, it can |
| 100 | be accessed. |
| 101 | |
| 102 | An array should be created by a user-space tool. This will write |
| 103 | superblocks to all devices. It will usually mark the array as |
| 104 | 'unclean', or with some devices missing so that the kernel md driver |
| 105 | can create appropriate redundancy (copying in raid1, parity |
| 106 | calculation in raid4/5). |
| 107 | |
| 108 | When an array is assembled, it is first initialized with the |
| 109 | SET_ARRAY_INFO ioctl. This contains, in particular, a major and minor |
| 110 | version number. The major version number selects which superblock |
| 111 | format is to be used. The minor number might be used to tune handling |
| 112 | of the format, such as suggesting where on each device to look for the |
| 113 | superblock. |
| 114 | |
| 115 | Then each device is added using the ADD_NEW_DISK ioctl. This |
| 116 | provides, in particular, a major and minor number identifying the |
| 117 | device to add. |
| 118 | |
| 119 | The array is started with the RUN_ARRAY ioctl. |
| 120 | |
| 121 | Once started, new devices can be added. They should have an |
| 122 | appropriate superblock written to them, and then passed be in with |
| 123 | ADD_NEW_DISK. |
| 124 | |
| 125 | Devices that have failed or are not yet active can be detached from an |
| 126 | array using HOT_REMOVE_DISK. |
| 127 | |
| 128 | |
| 129 | Specific Rules that apply to format-0 super block arrays, and |
| 130 | arrays with no superblock (non-persistent). |
| 131 | ------------------------------------------------------------- |
| 132 | |
| 133 | An array can be 'created' by describing the array (level, chunksize |
| 134 | etc) in a SET_ARRAY_INFO ioctl. This must has major_version==0 and |
| 135 | raid_disks != 0. |
| 136 | |
| 137 | Then uninitialized devices can be added with ADD_NEW_DISK. The |
| 138 | structure passed to ADD_NEW_DISK must specify the state of the device |
| 139 | and it's role in the array. |
| 140 | |
| 141 | Once started with RUN_ARRAY, uninitialized spares can be added with |
| 142 | HOT_ADD_DISK. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 143 | |
| 144 | |
| 145 | |
| 146 | MD devices in sysfs |
| 147 | ------------------- |
| 148 | md devices appear in sysfs (/sys) as regular block devices, |
| 149 | e.g. |
| 150 | /sys/block/md0 |
| 151 | |
| 152 | Each 'md' device will contain a subdirectory called 'md' which |
| 153 | contains further md-specific information about the device. |
| 154 | |
| 155 | All md devices contain: |
| 156 | level |
NeilBrown | d33a56d | 2006-10-03 01:15:58 -0700 | [diff] [blame] | 157 | a text file indicating the 'raid level'. e.g. raid0, raid1, |
| 158 | raid5, linear, multipath, faulty. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 159 | If no raid level has been set yet (array is still being |
NeilBrown | d33a56d | 2006-10-03 01:15:58 -0700 | [diff] [blame] | 160 | assembled), the value will reflect whatever has been written |
| 161 | to it, which may be a name like the above, or may be a number |
| 162 | such as '0', '5', etc. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 163 | |
| 164 | raid_disks |
| 165 | a text file with a simple number indicating the number of devices |
| 166 | in a fully functional array. If this is not yet known, the file |
| 167 | will be empty. If an array is being resized (not currently |
| 168 | possible) this will contain the larger of the old and new sizes. |
NeilBrown | da943b99 | 2006-01-06 00:20:54 -0800 | [diff] [blame] | 169 | Some raid level (RAID1) allow this value to be set while the |
| 170 | array is active. This will reconfigure the array. Otherwise |
| 171 | it can only be set while assembling an array. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 172 | |
NeilBrown | 3b34380 | 2006-01-06 00:20:47 -0800 | [diff] [blame] | 173 | chunk_size |
| 174 | This is the size if bytes for 'chunks' and is only relevant to |
| 175 | raid levels that involve striping (1,4,5,6,10). The address space |
| 176 | of the array is conceptually divided into chunks and consecutive |
| 177 | chunks are striped onto neighbouring devices. |
Matt LaPlante | 3f6dee9 | 2006-10-03 22:45:33 +0200 | [diff] [blame] | 178 | The size should be at least PAGE_SIZE (4k) and should be a power |
NeilBrown | 3b34380 | 2006-01-06 00:20:47 -0800 | [diff] [blame] | 179 | of 2. This can only be set while assembling an array |
| 180 | |
NeilBrown | 08a02ec | 2007-05-09 02:35:38 -0700 | [diff] [blame] | 181 | layout |
| 182 | The "layout" for the array for the particular level. This is |
| 183 | simply a number that is interpretted differently by different |
| 184 | levels. It can be written while assembling an array. |
| 185 | |
| 186 | reshape_position |
| 187 | This is either "none" or a sector number within the devices of |
| 188 | the array where "reshape" is up to. If this is set, the three |
| 189 | attributes mentioned above (raid_disks, chunk_size, layout) can |
| 190 | potentially have 2 values, an old and a new value. If these |
| 191 | values differ, reading the attribute returns |
| 192 | new (old) |
| 193 | and writing will effect the 'new' value, leaving the 'old' |
| 194 | unchanged. |
| 195 | |
NeilBrown | a35b0d6 | 2006-01-06 00:20:49 -0800 | [diff] [blame] | 196 | component_size |
| 197 | For arrays with data redundancy (i.e. not raid0, linear, faulty, |
| 198 | multipath), all components must be the same size - or at least |
| 199 | there must a size that they all provide space for. This is a key |
| 200 | part or the geometry of the array. It is measured in sectors |
| 201 | and can be read from here. Writing to this value may resize |
| 202 | the array if the personality supports it (raid1, raid5, raid6), |
| 203 | and if the component drives are large enough. |
| 204 | |
NeilBrown | 8bb93aa | 2006-01-06 00:20:50 -0800 | [diff] [blame] | 205 | metadata_version |
| 206 | This indicates the format that is being used to record metadata |
| 207 | about the array. It can be 0.90 (traditional format), 1.0, 1.1, |
| 208 | 1.2 (newer format in varying locations) or "none" indicating that |
| 209 | the kernel isn't managing metadata at all. |
| 210 | |
NeilBrown | a94213b | 2006-06-26 00:28:00 -0700 | [diff] [blame] | 211 | resync_start |
| 212 | The point at which resync should start. If no resync is needed, |
| 213 | this will be a very large number. At array creation it will |
| 214 | default to 0, though starting the array as 'clean' will |
| 215 | set it much larger. |
| 216 | |
NeilBrown | 6d7ff738 | 2006-01-06 00:21:16 -0800 | [diff] [blame] | 217 | new_dev |
| 218 | This file can be written but not read. The value written should |
| 219 | be a block device number as major:minor. e.g. 8:0 |
| 220 | This will cause that device to be attached to the array, if it is |
| 221 | available. It will then appear at md/dev-XXX (depending on the |
| 222 | name of the device) and further configuration is then possible. |
| 223 | |
NeilBrown | 16f17b3 | 2006-06-26 00:27:37 -0700 | [diff] [blame] | 224 | safe_mode_delay |
| 225 | When an md array has seen no write requests for a certain period |
| 226 | of time, it will be marked as 'clean'. When another write |
Matt LaPlante | fff9289 | 2006-10-03 22:47:42 +0200 | [diff] [blame] | 227 | request arrives, the array is marked as 'dirty' before the write |
| 228 | commences. This is known as 'safe_mode'. |
NeilBrown | 16f17b3 | 2006-06-26 00:27:37 -0700 | [diff] [blame] | 229 | The 'certain period' is controlled by this file which stores the |
| 230 | period as a number of seconds. The default is 200msec (0.200). |
| 231 | Writing a value of 0 disables safemode. |
| 232 | |
NeilBrown | 9e653b6 | 2006-06-26 00:27:58 -0700 | [diff] [blame] | 233 | array_state |
| 234 | This file contains a single word which describes the current |
| 235 | state of the array. In many cases, the state can be set by |
| 236 | writing the word for the desired state, however some states |
| 237 | cannot be explicitly set, and some transitions are not allowed. |
| 238 | |
| 239 | clear |
| 240 | No devices, no size, no level |
| 241 | Writing is equivalent to STOP_ARRAY ioctl |
| 242 | inactive |
| 243 | May have some settings, but array is not active |
| 244 | all IO results in error |
| 245 | When written, doesn't tear down array, but just stops it |
| 246 | suspended (not supported yet) |
| 247 | All IO requests will block. The array can be reconfigured. |
| 248 | Writing this, if accepted, will block until array is quiessent |
| 249 | readonly |
| 250 | no resync can happen. no superblocks get written. |
| 251 | write requests fail |
| 252 | read-auto |
| 253 | like readonly, but behaves like 'clean' on a write request. |
| 254 | |
| 255 | clean - no pending writes, but otherwise active. |
| 256 | When written to inactive array, starts without resync |
| 257 | If a write request arrives then |
| 258 | if metadata is known, mark 'dirty' and switch to 'active'. |
| 259 | if not known, block and switch to write-pending |
| 260 | If written to an active array that has pending writes, then fails. |
| 261 | active |
| 262 | fully active: IO and resync can be happening. |
| 263 | When written to inactive array, starts with resync |
| 264 | |
| 265 | write-pending |
| 266 | clean, but writes are blocked waiting for 'active' to be written. |
| 267 | |
| 268 | active-idle |
| 269 | like active, but no writes have been seen for a while (safe_mode_delay). |
| 270 | |
| 271 | |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 272 | As component devices are added to an md array, they appear in the 'md' |
| 273 | directory as new directories named |
| 274 | dev-XXX |
| 275 | where XXX is a name that the kernel knows for the device, e.g. hdb1. |
| 276 | Each directory contains: |
| 277 | |
| 278 | block |
| 279 | a symlink to the block device in /sys/block, e.g. |
| 280 | /sys/block/md0/md/dev-hdb1/block -> ../../../../block/hdb/hdb1 |
| 281 | |
| 282 | super |
| 283 | A file containing an image of the superblock read from, or |
| 284 | written to, that device. |
| 285 | |
| 286 | state |
| 287 | A file recording the current state of the device in the array |
| 288 | which can be a comma separated list of |
| 289 | faulty - device has been kicked from active use due to |
| 290 | a detected fault |
| 291 | in_sync - device is a fully in-sync member of the array |
NeilBrown | f655675 | 2006-06-26 00:28:01 -0700 | [diff] [blame] | 292 | writemostly - device will only be subject to read |
| 293 | requests if there are no other options. |
| 294 | This applies only to raid1 arrays. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 295 | spare - device is working, but not a full member. |
| 296 | This includes spares that are in the process |
Matt LaPlante | d6bc8ac | 2006-10-03 22:54:15 +0200 | [diff] [blame] | 297 | of being recovered to |
| 298 | This list may grow in future. |
NeilBrown | 45dc2de | 2006-06-26 00:27:58 -0700 | [diff] [blame] | 299 | This can be written to. |
| 300 | Writing "faulty" simulates a failure on the device. |
| 301 | Writing "remove" removes the device from the array. |
NeilBrown | f655675 | 2006-06-26 00:28:01 -0700 | [diff] [blame] | 302 | Writing "writemostly" sets the writemostly flag. |
| 303 | Writing "-writemostly" clears the writemostly flag. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 304 | |
NeilBrown | 4dbcdc7 | 2006-01-06 00:20:52 -0800 | [diff] [blame] | 305 | errors |
| 306 | An approximate count of read errors that have been detected on |
| 307 | this device but have not caused the device to be evicted from |
| 308 | the array (either because they were corrected or because they |
| 309 | happened while the array was read-only). When using version-1 |
| 310 | metadata, this value persists across restarts of the array. |
| 311 | |
| 312 | This value can be written while assembling an array thus |
| 313 | providing an ongoing count for arrays with metadata managed by |
| 314 | userspace. |
| 315 | |
NeilBrown | 014236d | 2006-01-06 00:20:55 -0800 | [diff] [blame] | 316 | slot |
| 317 | This gives the role that the device has in the array. It will |
| 318 | either be 'none' if the device is not active in the array |
| 319 | (i.e. is a spare or has failed) or an integer less than the |
Matt LaPlante | 992caac | 2006-10-03 22:52:05 +0200 | [diff] [blame] | 320 | 'raid_disks' number for the array indicating which position |
NeilBrown | 014236d | 2006-01-06 00:20:55 -0800 | [diff] [blame] | 321 | it currently fills. This can only be set while assembling an |
| 322 | array. A device for which this is set is assumed to be working. |
| 323 | |
NeilBrown | 93c8cad | 2006-01-06 00:20:56 -0800 | [diff] [blame] | 324 | offset |
| 325 | This gives the location in the device (in sectors from the |
| 326 | start) where data from the array will be stored. Any part of |
| 327 | the device before this offset us not touched, unless it is |
| 328 | used for storing metadata (Formats 1.1 and 1.2). |
| 329 | |
NeilBrown | 83303b6 | 2006-01-06 00:21:06 -0800 | [diff] [blame] | 330 | size |
| 331 | The amount of the device, after the offset, that can be used |
| 332 | for storage of data. This will normally be the same as the |
| 333 | component_size. This can be written while assembling an |
| 334 | array. If a value less than the current component_size is |
| 335 | written, component_size will be reduced to this value. |
| 336 | |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 337 | |
| 338 | An active md device will also contain and entry for each active device |
| 339 | in the array. These are named |
| 340 | |
| 341 | rdNN |
| 342 | |
Matt LaPlante | 992caac | 2006-10-03 22:52:05 +0200 | [diff] [blame] | 343 | where 'NN' is the position in the array, starting from 0. |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 344 | So for a 3 drive array there will be rd0, rd1, rd2. |
| 345 | These are symbolic links to the appropriate 'dev-XXX' entry. |
| 346 | Thus, for example, |
| 347 | cat /sys/block/md*/md/rd*/state |
| 348 | will show 'in_sync' on every line. |
| 349 | |
| 350 | |
| 351 | |
| 352 | Active md devices for levels that support data redundancy (1,4,5,6) |
| 353 | also have |
| 354 | |
| 355 | sync_action |
| 356 | a text file that can be used to monitor and control the rebuild |
| 357 | process. It contains one word which can be one of: |
| 358 | resync - redundancy is being recalculated after unclean |
| 359 | shutdown or creation |
| 360 | recover - a hot spare is being built to replace a |
| 361 | failed/missing device |
| 362 | idle - nothing is happening |
| 363 | check - A full check of redundancy was requested and is |
| 364 | happening. This reads all block and checks |
| 365 | them. A repair may also happen for some raid |
| 366 | levels. |
| 367 | repair - A full check and repair is happening. This is |
| 368 | similar to 'resync', but was requested by the |
| 369 | user, and the write-intent bitmap is NOT used to |
| 370 | optimise the process. |
| 371 | |
| 372 | This file is writable, and each of the strings that could be |
| 373 | read are meaningful for writing. |
| 374 | |
| 375 | 'idle' will stop an active resync/recovery etc. There is no |
| 376 | guarantee that another resync/recovery may not be automatically |
| 377 | started again, though some event will be needed to trigger |
| 378 | this. |
| 379 | 'resync' or 'recovery' can be used to restart the |
| 380 | corresponding operation if it was stopped with 'idle'. |
| 381 | 'check' and 'repair' will start the appropriate process |
| 382 | providing the current state is 'idle'. |
| 383 | |
| 384 | mismatch_count |
| 385 | When performing 'check' and 'repair', and possibly when |
| 386 | performing 'resync', md will count the number of errors that are |
| 387 | found. The count in 'mismatch_cnt' is the number of sectors |
| 388 | that were re-written, or (for 'check') would have been |
| 389 | re-written. As most raid levels work in units of pages rather |
| 390 | than sectors, this my be larger than the number of actual errors |
| 391 | by a factor of the number of sectors in a page. |
| 392 | |
Paul Clements | 9b1d1da | 2006-10-03 01:15:49 -0700 | [diff] [blame] | 393 | bitmap_set_bits |
| 394 | If the array has a write-intent bitmap, then writing to this |
| 395 | attribute can set bits in the bitmap, indicating that a resync |
| 396 | would need to check the corresponding blocks. Either individual |
| 397 | numbers or start-end pairs can be written. Multiple numbers |
| 398 | can be separated by a space. |
| 399 | Note that the numbers are 'bit' numbers, not 'block' numbers. |
| 400 | They should be scaled by the bitmap_chunksize. |
| 401 | |
NeilBrown | 08a02ec | 2007-05-09 02:35:38 -0700 | [diff] [blame] | 402 | sync_speed_min |
| 403 | sync_speed_max |
| 404 | This are similar to /proc/sys/dev/raid/speed_limit_{min,max} |
| 405 | however they only apply to the particular array. |
| 406 | If no value has been written to these, of if the word 'system' |
| 407 | is written, then the system-wide value is used. If a value, |
| 408 | in kibibytes-per-second is written, then it is used. |
| 409 | When the files are read, they show the currently active value |
| 410 | followed by "(local)" or "(system)" depending on whether it is |
| 411 | a locally set or system-wide value. |
| 412 | |
| 413 | sync_completed |
| 414 | This shows the number of sectors that have been completed of |
| 415 | whatever the current sync_action is, followed by the number of |
| 416 | sectors in total that could need to be processed. The two |
| 417 | numbers are separated by a '/' thus effectively showing one |
| 418 | value, a fraction of the process that is complete. |
NeilBrown | c620727 | 2008-02-06 01:39:52 -0800 | [diff] [blame] | 419 | A 'select' on this attribute will return when resync completes, |
| 420 | when it reaches the current sync_max (below) and possibly at |
| 421 | other times. |
| 422 | |
| 423 | sync_max |
| 424 | This is a number of sectors at which point a resync/recovery |
| 425 | process will pause. When a resync is active, the value can |
| 426 | only ever be increased, never decreased. The value of 'max' |
| 427 | effectively disables the limit. |
| 428 | |
NeilBrown | 08a02ec | 2007-05-09 02:35:38 -0700 | [diff] [blame] | 429 | |
| 430 | sync_speed |
| 431 | This shows the current actual speed, in K/sec, of the current |
| 432 | sync_action. It is averaged over the last 30 seconds. |
| 433 | |
| 434 | suspend_lo |
| 435 | suspend_hi |
| 436 | The two values, given as numbers of sectors, indicate a range |
| 437 | within the array where IO will be blocked. This is currently |
| 438 | only supported for raid4/5/6. |
| 439 | |
| 440 | |
NeilBrown | bb63654 | 2005-11-08 21:39:45 -0800 | [diff] [blame] | 441 | Each active md device may also have attributes specific to the |
| 442 | personality module that manages it. |
| 443 | These are specific to the implementation of the module and could |
| 444 | change substantially if the implementation changes. |
| 445 | |
| 446 | These currently include |
| 447 | |
| 448 | stripe_cache_size (currently raid5 only) |
| 449 | number of entries in the stripe cache. This is writable, but |
| 450 | there are upper and lower limits (32768, 16). Default is 128. |
| 451 | strip_cache_active (currently raid5 only) |
| 452 | number of active entries in the stripe cache |