striped + single parity
Derived by hand from the Linux md rule — how the pages are sourced
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 is the pair striped + single parity: the data is dealt out in chunks across all the members (striping), and in every stripe one chunk holds the XOR of the others (parity). It is the fifth level of the 1988 paper, and the one the paper builds up to: the fourth level had put all the parity on one disk, and "the check disk is the bottleneck"; the fifth "distributes the data and check information across all the disks". Which disk holds the parity in which stripe is the placement algorithm, almost always left-symmetric.
Capacity, first. A mirror spends half the disks on copies; RAID 5 spends one disk's worth on parity whatever the count, so on four disks it keeps three quarters, on eight seven eighths. The fault tolerance is one disk, on any count, and the disk count is the risk: the more disks, the more space, the more likely a second failure while the first is being rebuilt.
The write. A block changed in place must keep the parity of its stripe true, and to compute the new parity the engine needs two things it does not have in hand: the old data and the old parity. So one logical write becomes four disk operations, in this order:
Two reads the write would not otherwise need, and two writes that must wait for them: this is the write penalty of single parity. It is paid by every small write, one that changes a block and leaves the rest of the stripe as it was. A write that covers a whole stripe pays none of the reads: every data block is already in hand, the parity is computed from them, and the cost is one write per member. That is the trade. RAID 5 is at its best under large sequential writes and worst under many small scattered ones, and the chunk size and the file system's alignment decide which of the two a workload gets.
Three disks is the minimum that makes sense: two data, one parity per stripe. An array built with two disks is a different thing from a three-disk array that has lost one. The second is a RAID 5 running degraded: every stripe still has a data block and a parity block on the survivors, the missing block is recomputed by XOR on every read, and nothing is a copy of anything. The first has one data block per stripe, and the "parity" of a single block is that block itself: disk 0 and disk 1 hold the same content, and the array is a mirror by another name. The Linux kernel relies on exactly that, on request, when an administrator grows a mirror into a RAID 5: the first step, raid5_takeover_raid1(), relabels the two-disk RAID 1 as a two-disk RAID 5 without moving a byte, because on two disks the two layouts are the same; only then are disks added and the data redistributed. Such an array writes at a mirror's cost, two operations. The rebuild after a failure reads every surviving disk end to end; an unreadable sector found then is a block that cannot be recomputed, which is what scrubbing exists to catch earlier, and a power cut during a parity update leaves a write hole that only a protected cache, a journal or a partial parity log closes.
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.
RAID 5 · 4 disks · left-symmetric
disk 0 disk 1 disk 2 disk 3
stripe 0 D0 D1 D2 P
stripe 1 D4 D5 P D3
stripe 2 D8 P D6 D7
stripe 3 P D9 D10 D11How 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.
(N − 1) × disk size
N = 4 disks of 2 TB → (4 − 1) × 2 TB = 6 TB usable
the members an adversary must kill, minus one
single parity: two members gone is one too many → 2 → tolerance 1
one logical write costs
random: read old data, read old parity, write both → 4 I/Os
sequential: a full stripe computes the parity once → 1 I/OThe 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.
Read more — Placement algorithm
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.
Open this example in the sandbox
A desktop link: below the desktop breakpoint the sandbox is not offered (ADR-003).