Map
RAID combines multiple physical drives into a single logical unit to improve performance, reliability, or both. Originally described in a 1988 UC Berkeley paper, it remains a core building block of storage systems — from workstations to enterprise data centers.
The raw drives, hard disks or SSDs, each with its own capacity and its own interface: SATA, SAS or NVMe. On its own a disk just holds data, with no protection and no help from anything above it. Every layer above exists to turn a set of them into something more useful than one disk at a time.
The set of physical disks a controller gathers together to work with. A drive group is a pool, not a layout: it marks off "these disks are mine to arrange", and the arranging, striping, mirroring or parity, happens one layer down.
A set of disks sharing one layout: one striping, mirroring or parity scheme. A span is where a RAID level actually applies. A drive group can hold several spans, each with its own independent layout, and the nested levels are spans striped together.
The logical volume the operating system sees: one block device with a contiguous address space, behaving exactly like a single disk. It behaves that way whatever number of disks, spans or RAID levels sit underneath. It need not take the whole span; a span can host several.
Data dealt out in chunks across every disk and nothing else: no copy, no parity. Every disk works on every large request, so it is the fastest layout there is and uses all the space; and any one disk failing loses everything on all of them.
Every disk holds a full copy of the data, written in step. A read is served by any one copy, a write goes to all of them, and the array survives as long as one copy is left. It keeps one disk's worth of space however many disks it has, and it is the simplest redundancy there is.
Data striped across every disk, with one parity block per stripe that moves from disk to disk. Any one disk can fail and everything on it is recomputed from the rest by XOR. It keeps all but one disk's worth of space, reads nearly as fast as a plain stripe, and pays for small writes with four disk operations each.
RAID 5 with a second parity block per stripe, computed a different way, so that any two disks can fail at once. It keeps all but two disks' worth of space, survives a second failure during a rebuild, and pays for each small write with six disk operations.
Striping and mirroring in one flat array: every chunk is stored on two disks, and the chunks are dealt across all of them. It reads like a stripe, writes at a mirror's cost with no parity to compute, keeps half the space, and is guaranteed to survive one failure, more if the failures miss each other.
How an array splits its data across its member disks. Striped cuts the data into fixed-size chunks and deals them out to every member in turn; linear writes it as one run, filling the first member before touching the next. Segmentation is about how many disks take part in one request, not about whether the data survives a failure.
Cutting data into fixed-size chunks and dealing them out across several disks in turn. One large request is then served by all of them at once, and many small requests by different disks at the same time. It multiplies speed by the number of disks and multiplies the chance of losing everything by the same number.
The chunk is the piece of a stripe that lands on one disk: what Linux `md` calls a chunk and most controllers a strip. Its size is fixed when the array is created and it is the unit striping deals out, so it sets how many disks one request touches. A stripe is one round of chunks, one per member.
The rule that says, stripe by stripe, which member holds the parity and where the data starts, or where a mirror's copies go. The level says what is stored; the algorithm says where. Left-symmetric for the parity levels and near for RAID 10 are the defaults nearly everything uses. The choice changes speed and compatibility, not capacity or safety.
How an array keeps its data readable when a member fails: by storing more than the data itself. Two techniques do it. Mirroring keeps whole copies on separate disks; parity keeps a computed summary from which any one missing block, or two with a second parity, can be rebuilt. Redundancy always costs capacity; the question is how much, and how many failures it buys.
Keeping every block in full on two or more disks. A write goes to every copy; a read is served by any one of them. Lose all copies but one and the data is still there. The cost is that the disks hold one disk's worth of data between them, or half of their sum when the copies are striped across a larger set, as in RAID 10.
One extra block per stripe, computed from the stripe's data blocks by XOR, from which any single missing block can be recomputed. It protects a whole stripe at the cost of one block instead of a full copy. A second block computed a different way, the Q of RAID 6, covers two failures at the cost of two.
How much of the raw disk space an array leaves usable for data. Raw capacity is the sum of the members; usable capacity is what remains after the redundancy takes its share: nothing for striping or concatenation, all but one copy for a mirror, one member's worth for each parity block in the stripe.
How many disks can fail, in the worst place, before data is lost. It comes from the redundancy: none tolerates zero, a mirror all copies but one, single parity one, double parity two. In a nested level the worst place matters: a RAID 50 survives one failure per span, but two in the same span lose everything.
How many disk operations one logical write costs. A plain write is one; a mirror writes every copy; a small parity write must read the old data and the old parity before writing the new ones, four operations for single parity and six for double. A write that covers a whole stripe pays no read.
How fast an array reads and writes, relative to one disk. Two quantities decide it: how many disks take part in a request, which comes from the segmentation, and how many operations one write costs, which comes from the redundancy. Reads scale with the disks that can serve them; writes scale with the disks divided by the penalty.
Writing a replaced disk back from the redundancy: copying the surviving mirror, or recomputing every stripe from data and parity. Until it finishes the array is degraded, slower, and one failure away from loss. The time it takes is a reliability number, and a hot spare is what lets it start with nobody present.
Reading every block of an array in the background to find errors before a rebuild does: sectors that cannot be read, and copies or parity that no longer match. Linux md calls the pass a check or a repair; controllers call it patrol read and consistency check.
The gap between writing a stripe's data and writing its parity. A power cut in that gap leaves a parity that no longer matches its data, and nothing in the array notices until a rebuild uses the wrong parity to recompute a missing disk. It affects the parity levels on any engine whose writes are not protected; a battery-backed cache, a journal, or a partial parity log closes it.
A battery or supercapacitor that lets a hardware RAID controller keep its write cache through a power cut. The battery powers the cache memory until power returns; the supercapacitor, in newer designs, powers the controller just long enough to copy the cache to flash. It is what makes write-back caching safe on a controller, and what closes the write hole there.
Redundancy keeps an array running when a disk fails. It does nothing for the other ways data is lost: a deletion, an overwrite, malware, a failed controller, fire, a second failure during a rebuild. A backup is a separate copy, made at a point in time, kept where the array's failures cannot reach it.
The component that turns a RAID layout into disk operations. It owns the array's metadata, translates every request from the array's addresses to the members', writes the copies or computes the parity, and keeps serving when a disk fails. It is a role, not a fixed device: a RAID-on-Chip on a controller card, the operating system's own driver, or a boot firmware working with that driver.
The host bus adapter: the card, or the chipset function, that speaks SATA or SAS to the disks on one side and PCIe to the CPU on the other. It translates the protocol and passes each disk through unchanged, so the operating system sees every one of them. It computes no RAID. A RAID controller card is an HBA with a RAID engine added.
The board the disks plug into, on the path between them and the HBA or the controller. A passive backplane only routes the SATA or SAS signals from each disk bay to a connector; an active one carries a SAS expander, a switch that lets one cable reach many disks. Either way it stores nothing and computes no RAID.
These pages take the Linux `md` driver as their reference because its source is public. Every statement is marked by where a reader can check it: a public source, a derivation kept with the code, or not yet. Where a source leaves something open, the choice the sandbox made is a note on the page that rests on it, and this page lists them all.