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.
(N − 1) ÷ N of the raw total, three quarters on four disks, seven eighths on eight. A mirror keeps one half.N − 1 data chunks of a stripe are read in parallel, close to a plain stripe of the same width (performance).Write cost. 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.
Workload dependence. RAID 5 is at its best under large sequential writes and worst under many small scattered ones; 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.
The grid below is the placement of a RAID 5 array of 4 disks, as the Linux md rule produces it. Each column is one disk, each row is one stripe, and each cell names the block that lands there: D followed by a number for a data chunk, and P for the parity block of the stripe. Reading a row from left to right shows how one stripe is dealt across the members; reading a column from top to bottom shows what one disk ends up holding.
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 covers.
Three quantities follow from the redundancy alone: usable capacity, fault tolerance and write penalty. Below they are worked out for the example array, 4 disks of 2 TB each. Each block states the general rule on its first line, then substitutes the numbers of the example on the lines that follow.
(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
A placement algorithm decides where the parity blocks or the copies go within each stripe. The list below is the set of algorithms this level accepts, each with what it does; the one marked default is what mdadm chooses when none is named.
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.
In any given system, exactly one component holds the role of RAID engine: a hardware controller with its own processor, a firmware chip that keeps the metadata while the operating system's driver does the work, or the operating system alone. They are alternatives, not layers, so a system has one of them and not the others. The list below names the components that can hold that role for a RAID 5 array, and what each of them does with the level.
On the components below, a power loss during a write can leave a stripe inconsistent, because nothing protects the write cache:
Every level has a disk count below which it is no longer itself. Linux md starts a RAID 5 with fewer disks anyway, and what runs then is a simpler level under the name of the one requested. The rows below give the smallest array that is a RAID 5, the smallest one Linux md still starts under that name, and what the array actually is at each count in between.
Open this example in the sandbox
A desktop link: on a phone or in a narrow window the sandbox is not offered.