A kernel. Preferably a kernel from the 2.4 series. Alternatively
a 2.0 or 2.2 kernel with the RAID patches applied.

The RAID tools.

Patience, Pizza, and your favorite caffeinated beverage.

All of this is included as standard in most GNU/Linux distributions
today.

If your system has RAID support, you should have a file called
/proc/mdstat. Remember it, that file is your friend. If you do not have
that file, maybe your kernel does not have RAID support. See what the
contains, by doing a cat /proc/mdstat. It should tell you that
you have the right RAID personality (eg. RAID mode) registered, and
that no RAID devices are currently active.

Spare-disks are not supported here. If a disk dies, the array dies
with it. There's no information to put on a spare disk.

You're probably wondering why we specify a chunk-size here
when linear mode just appends the disks into one large array with no
parallelism. Well, you're completely right, it's odd. Just put in some
chunk size and don't worry about this any more.

Ok, let's create the array. Run the command

mkraid /dev/md0

This will initialize your array, write the persistent superblocks, and
start the array.

You have two devices of approximately same size, and you want the two
to be mirrors of each other. Eventually you have more devices, which
you want to keep as stand-by spare-disks, that will automatically
become a part of the mirror if one of the active devices break.

If you have spare disks, you can add them to the end of the device
specification like

device /dev/sdd5
spare-disk 0

Remember to set the nr-spare-disks entry correspondingly.

Ok, now we're all set to start initializing the RAID. The mirror must
be constructed, eg. the contents (however unimportant now, since the
device is still not formatted) of the two devices must be
synchronized.

Issue the

mkraid /dev/md0

command to begin the mirror initialization.

Check out the /proc/mdstat file. It should tell you that the /dev/md0
device has been started, that the mirror is being reconstructed, and
an ETA of the completion of the reconstruction.

Reconstruction is done using idle I/O bandwidth. So, your system
should still be fairly responsive, although your disk LEDs should be
glowing nicely.

The reconstruction process is transparent, so you can actually use the
device even though the mirror is currently under reconstruction.

Try formatting the device, while the reconstruction is running. It
will work. Also you can mount it and use it while reconstruction is
running. Of Course, if the wrong disk breaks while the reconstruction
is running, you're out of luck.

Note! I haven't tested this setup myself. The setup below is
my best guess, not something I have actually had up running. If you
use RAID-4, please write to the
author and share
your experiences.

You have three or more devices of roughly the same size, one device is
significantly faster than the other devices, and you want to combine
them all into one larger device, still maintaining some redundancy
information.
Eventually you have a number of devices you wish to use as
spare-disks.

You have three or more devices of roughly the same size, you want to
combine them into a larger device, but still to maintain a degree of
redundancy for data safety. Eventually you have a number of devices to
use as spare-disks, that will not take part in the array before
another device fails.

If you use N devices where the smallest has size S, the size of the
entire array will be (N-1)*S. This "missing" space is used for
parity (redundancy) information. Thus, if any disk fails, all data
stay intact. But if two disks fail, all data is lost.

If we had any spare disks, they would be inserted in a similar way,
following the raid-disk specifications;

device /dev/sdh1
spare-disk 0

And so on.

A chunk size of 32 kB is a good default for many general purpose
filesystems of this size. The array on which the above raidtab is
used, is a 7 times 6 GB = 36 GB (remember the (n-1)*s = (7-1)*6 = 36)
device. It holds an ext2 filesystem with a 4 kB block size. You could
go higher with both array chunk-size and filesystem block-size if your
filesystem is either much larger, or just holds very large files.

Ok, enough talking. You set up the /etc/raidtab, so let's see if it
works. Run the

mkraid /dev/md0

command, and see what happens. Hopefully your disks start working
like mad, as they begin the reconstruction of your array. Have a look
in /proc/mdstat to see what's going on.

If the device was successfully created, the reconstruction process has
now begun. Your array is not consistent until this reconstruction
phase has completed. However, the array is fully functional (except
for the handling of device failures of course), and you can format it
and use it even while it is reconstructing.

See the section on special options for mke2fs before formatting the
array.

Ok, now when you have your RAID device running, you can always stop it
or re-start it using the

raidstop /dev/md0

or

raidstart /dev/md0

commands.

With mdadm you can stop the device using

mdadm -S /dev/md0

and re-start it with

mdadm -R /dev/md0

Instead of putting these into init-files and rebooting a zillion times
to make that work, read on, and get autodetection running.

Back in "The Good Old Days" (TM), the raidtools would read your
/etc/raidtab file, and then initialize the array. However, this would
require that the filesystem on which /etc/raidtab resided was
mounted. This is unfortunate if you want to boot on a RAID.

Also, the old approach led to complications when mounting filesystems
on RAID devices. They could not be put in the /etc/fstab file as usual,
but would have to be mounted from the init-scripts.

The persistent superblocks solve these problems. When an array is
initialized with the persistent-superblock option in the
/etc/raidtab file, a special superblock is written in the beginning of
all disks participating in the array. This allows the kernel to read
the configuration of RAID devices directly from the disks involved,
instead of reading from some configuration file that may not be
available at all times.

You should however still maintain a consistent /etc/raidtab file, since
you may need this file for later reconstruction of the array.

The persistent superblock is mandatory if you want auto-detection of
your RAID devices upon system boot. This is described in the
Autodetection section.

The chunk-size deserves an explanation. You can never write
completely parallel to a set of disks. If you had two disks and wanted
to write a byte, you would have to write four bits on each disk,
actually, every second bit would go to disk 0 and the others to disk
1. Hardware just doesn't support that. Instead, we choose some
chunk-size, which we define as the smallest "atomic" mass of data
that can be written to the devices. A write of 16 kB with a chunk
size of 4 kB, will cause the first and the third 4 kB chunks to be
written to the first disk, and the second and fourth chunks to be
written to the second disk, in the RAID-0 case with two disks. Thus,
for large writes, you may see lower overhead by having fairly large
chunks, whereas arrays that are primarily holding small files may
benefit more from a smaller chunk size.

Chunk sizes must be specified for all RAID levels, including linear
mode. However, the chunk-size does not make any difference for linear
mode.

For optimal performance, you should experiment with the value, as well
as with the block-size of the filesystem you put on the array.

The argument to the chunk-size option in /etc/raidtab specifies the
chunk-size in kilobytes. So "4" means "4 kB".

RAID-0

Data is written "almost" in parallel to the disks in the
array. Actually, chunk-size bytes are written to each disk,
serially.

If you specify a 4 kB chunk size, and write 16 kB to an array of three
disks, the RAID system will write 4 kB to disks 0, 1 and 2, in
parallel, then the remaining 4 kB to disk 0.

A 32 kB chunk-size is a reasonable starting point for most arrays. But
the optimal value depends very much on the number of drives involved,
the content of the file system you put on it, and many other factors.
Experiment with it, to get the best performance.

RAID-0 with ext2

There is more disk activity at the beginning of ext2fs block groups.
On a single disk, that does not matter, but it can hurt RAID0, if all
block groups happen to begin on the same disk. Example:

With 4k stripe size and 4k block size, each block occupies one stripe.
With two disks, the stripe-#disk-product is 2*4k=8k. The default
block group size is 32768 blocks, so all block groups start on disk 0,
which can easily become a hot spot, thus reducing overall performance.
Unfortunately, the block group size can only be set in steps of 8 blocks
(32k when using 4k blocks), so you can not avoid the problem by adjusting
the block group size with the -g option of mkfs(8).

If you add a disk, the stripe-#disk-product is 12, so the first block
group starts on disk 0, the second block group starts on disk 2 and the
third on disk 1. The load caused by disk activity at the block group
beginnings spreads over all disks.

In case you can not add a disk, try a stripe size of 32k. The
stripe-#disk-product is 64k. Since you can change the block group size
in steps of 8 blocks (32k), using a block group size of 32760 solves
the problem.

Additionally, the block group boundaries should fall on stripe boundaries.
That is no problem in the examples above, but it could easily happen
with larger stripe sizes.

RAID-1

For writes, the chunk-size doesn't affect the array, since all data
must be written to all disks no matter what. For reads however, the
chunk-size specifies how much data to read serially from the
participating disks. Since all active disks in the array
contain the same information, the RAID layer has complete freedom in
choosing from which disk information is read - this is used by the
RAID code to improve average seek times by picking the disk best
suited for any given read operation.

RAID-4

When a write is done on a RAID-4 array, the parity information must be
updated on the parity disk as well.

The chunk-size affects read performance in the same way as in RAID-0,
since reads from RAID-4 are done in the same way.

RAID-5

On RAID-5, the chunk size has the same meaning for reads as for
RAID-0. Writing on RAID-5 is a little more complicated: When a chunk
is written on a RAID-5 array, the corresponding parity chunk must be
updated as well. Updating a parity chunk requires either

The original chunk, the new chunk, and the old parity block

Or, all chunks (except for the parity chunk) in the stripe

The RAID code will pick the easiest way to update each parity chunk as
the write progresses. Naturally, if your server has lots of memory
and/or if the writes are nice and linear, updating the parity chunks
will only impose the overhead of one extra write going over the bus
(just like RAID-1). The parity calculation itself is extremely
efficient, so while it does of course load the main CPU of the system,
this impact is negligible. If the writes are small and scattered all
over the array, the RAID layer will almost always need to read in all
the untouched chunks from each stripe that is written to, in order to
calculate the parity chunk. This will impose extra bus-overhead and
latency due to extra reads.

A reasonable chunk-size for RAID-5 is 128 kB, but as always, you may
want to experiment with this.

Also see the section on special options for mke2fs. This affects
RAID-5 performance.

There is a special option available when formatting RAID-4 or -5
devices with mke2fs. The -R stride=nn option will allow
mke2fs to better place different ext2 specific data-structures in an
intelligent way on the RAID device.

If the chunk-size is 32 kB, it means, that 32 kB of consecutive data
will reside on one disk. If we want to build an ext2 filesystem with 4
kB block-size, we realize that there will be eight filesystem blocks
in one array chunk. We can pass this information on the mke2fs
utility, when creating the filesystem:

mke2fs -b 4096 -R stride=8 /dev/md0

RAID-{4,5} performance is severely influenced by this option. I am
unsure how the stride option will affect other RAID levels. If anyone
has information on this, please send it in my direction.

The ext2fs blocksize severely influences the performance of
the filesystem. You should always use 4kB block size on any filesystem
larger than a few hundred megabytes, unless you store a very large
number of very small files on it.