To fix this, a new version of the superblock was defined, version 1. Arrays with a v0.9 superblock can be assembled by the kernel but again, if drives were moved between machines, the consequences could be disastrous as the array would be assembled incorrectly. It is also ambiguous, leading to sysadmin confusion, never a good idea. However, it lacks support for most of the modern features of mdadm, and is now obsolete. It's also referred to as the version 0 superblock, 0 referring to the internals of the superblock. Presumably to fix this, the 0.9 version superblock was defined, stored at the end of the device. mdadm still supports this sort of array with the -build option. Only linear and raid-0 were supported at this time, so there was no redundancy to recover from. Adding a new drive could move the device names around and, relying on "raidtab", when the array was assembled it could get the wrong drives in the wrong place. This obviously could lead to a disaster if drives were moved between machines, as they were identified by their partition type. The first arrays did not have a superblock, and were declared in "raidtab", which was managed by the now-defunct "raid-tools". This contains all the bits that don't really fit anywhere else.Īrray internals and how it affects mdadm Superblocks and Raid versions Because there are no superblocks, or indeed, any array metadata, the system just has to assume you got everything right because it has no way of checking up on you. It is used to (re)create an array, and should not be used unless you know exactly what you are doing. This is a relic of when superblocks didn't exist. It can be confusing, as several options (such as -add) are also used in grow mode, most typically when adding a device at the same time as changing the number of devices. This is the default mode, and is used primarily to add and remove devices. This is why raids 5&6 are created in degraded mode - if they weren't then any check of the raid would spew errors for areas that hadn't been written to.Ī bit of a misnomer, this mode takes care of all operations that change the size of an array, such as changing the raid level, changing the number of active devices, etc. It also fires off initialisation - making sure that the disks of a mirror are identical, or that on a parity array the parities are correct. As the name implies, it creates arrays, and writes the superblocks for arrays that have them. This is the first of the two modes you will use a lot.
This is why you need an initramfs when booting off a raid array - because mdadm is a user-space program, if root is on an array then we have a catch-22 - we can't boot until we have root, and we can't have root until we've booted and can run mdadm.
It scans the drives, looking for superblocks, and rebuilds all the arrays for you.
Every time the system is booted, this needs to run. This is probably the mode that is used most, but you won't be using it much - it happens in the background. You will normally only use a few of them.
#SOFTRAID MANUAL INSTALL#
As a linux-specific program there is none of this autoconf stuff - just follow the instructions as per the INSTALL file.ĭo not use Neil Brown's version unless he tells you to do so - he is no longer the maintainer and it is not kept up-to-date. In the absence of any other preferences, it belongs in the /usr/local/src directory. Git clone git:///pub/scm/utils/mdadm/mdadm.git If, however, you are having any problems it does help to be running the absolute latest version, which can be downloaded with
#SOFTRAID MANUAL SOFTWARE#
This is a pretty standard part of any distro, so you should use your standard distro software management tool. There are a few things that need to be done by writing to the /proc filesystem, but not much. It manages nearly all the user space side of raid. Mdadm has replaced all the previous tools for managing raid arrays. 5.3.4 Adding more space without adding another device.5.3.2 Upgrading a mirror raid to a parity raid.4 Array internals and how it affects mdadm.
0 kommentar(er)
