JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

RAID: Speed, Redundancy, and the Rebuild Problem

One disk is slow and one disk dies. RAID glues several disks into one that is faster, or tougher, or both — by striping, mirroring, and parity. We build the levels from scratch, do the parity by hand, and then face the uncomfortable truth that almost everyone forgets: rebuilding after a failure is its own dangerous moment.

Why one disk is never enough

By now you know two hard facts about a single drive. From the earlier guides in this rung, a hard disk is achingly slow because every access pays seek and rotation, and it sits at the slow, distant bottom of the storage hierarchy. And from plain experience, a disk is a mechanical thing that eventually breaks — bearings wear, heads crash, a flash drive exhausts its erase cycles. So a single disk gives you two separate problems at once: it is too slow, and it is a single point of failure where one death takes all your data with it.

RAID — Redundant Array of Independent Disks — is the simple, powerful idea of ganging several cheap disks together and presenting them to the OS as one fast, tough drive. The trick is that with many disks you can do two things you could never do with one: spread the work across them so reads and writes happen in parallel (more speed), and store some data twice or store extra check information so that a dead disk can be reconstructed from the survivors (more safety). Almost every RAID design is some recipe for buying speed, safety, or both — and the whole art is in the trade-offs between them.

Striping and mirroring: the two raw moves

Start with the two basic moves; every named RAID level is built from these. Striping (RAID 0) chops your data into fixed-size chunks and lays consecutive chunks across the disks in rotation — chunk 0 on disk A, chunk 1 on disk B, chunk 2 on disk C, chunk 3 back on disk A, and so on. Now a big read or write that spans several chunks hits all the disks at once, so with N disks you can move roughly N times the data per second. It is pure speed and pure capacity: every byte of every disk holds your data, nothing wasted. But there is zero redundancy — the very opposite of what the R stands for. Any one disk dying scatters holes through every file, and the array is gone. Striping over N disks is actually N times MORE likely to lose data than one disk, because any of the N can kill it.

Mirroring (RAID 1) is the opposite instinct: keep two complete copies, one on each of two disks, written in lockstep. Now a single disk failure costs you nothing — the OS just reads from the survivor, and you replace the dead disk at leisure. Reads can even be a bit faster, since either copy can serve a request. The price is blunt and unavoidable: you pay for two disks and get the capacity of one. Half your money buys safety, not space. Mirroring is the simplest, most trustworthy redundancy there is, and it is still the right choice when the data is precious and you do not have many disks.

So the two raw moves stake out the extremes. Striping is all speed and capacity and no safety; mirroring is all safety and pays for it in half your capacity. The interesting RAID levels live in between, and they get there with one beautiful trick that gives you redundancy for the cost of a single extra disk instead of doubling everything: parity.

Parity: redundancy on the cheap

Parity is one of those ideas that feels like magic until you do it once by hand, after which it feels obvious. The core operation is XOR (exclusive or), which has one property we exploit: XOR everything together to make a parity block, and you can then recover ANY one missing block by XOR-ing all the others. It is the same arithmetic as a school trick — if you know that a + b + c = 17 and someone erases b, you recover b because you know a, c, and the total. Parity is that total, computed bitwise. The everyday way to feel it: among the data bits plus the parity bit, the count of 1s is always even, so if one bit goes missing you know what it must have been to keep the count even.

Three data disks + one parity disk.  P = D0 XOR D1 XOR D2

           bit pattern (one column)        count of 1s
  D0:           1                               \
  D1:           0                                |  data
  D2:           1                               /
  P :           0   (= 1 XOR 0 XOR 1)         total is even

Disk D1 dies.  Rebuild it from the survivors:
  D1 = D0 XOR D2 XOR P  =  1 XOR 1 XOR 0  =  0    <- recovered!
Parity = the XOR of the data blocks. Lose any one block and XOR the rest to bring it back. One extra disk protects N data disks.

This is the heart of RAID 5: stripe the data across N disks for speed, and on each stripe devote one disk's worth of space to the parity of that stripe — but rotate WHICH disk holds the parity from stripe to stripe, so no single disk becomes a write bottleneck. With N disks you get the capacity of N minus 1 (only one disk's worth is "lost" to parity, no matter how many disks you have), full striped read speed, and survival of any one disk dying. That is a wonderful deal: mirroring's protection at a fraction of mirroring's cost. RAID 6 takes it one honest step further — two independent parity blocks per stripe — so it can survive any TWO disks failing at once, at the cost of two disks' worth of capacity. Hold on to why anyone would want to survive a second failure; it is the whole point of the last section.

The trade-off table, and where the costs hide

Let us pin the common levels side by side so the trade-offs are concrete, imagining four 1 TB disks. RAID 0 (stripe): 4 TB usable, fastest, survives zero failures. RAID 1 (mirror, as two pairs or one big mirror): 2 TB usable, survives a failure in each mirror, simple and reliable. RAID 5 (stripe + one parity): 3 TB usable, survives one failure, good all-rounder. RAID 6 (stripe + two parity): 2 TB usable, survives any two failures, the choice for big arrays. RAID 10 (mirror first, then stripe the mirrors): 2 TB usable, fast AND tough, the favourite when you can afford the disks. Notice the universal pattern: more safety costs either capacity or write speed, never free.

Parity is not free at write time either, and this is the honest catch with RAID 5 and 6. To change a single block, the array cannot just overwrite it — the parity for that whole stripe would then be wrong. It must read the old data block and the old parity, compute the new parity, and write back both the data and the parity: roughly a read-read-write-write for one small write. This small-write penalty is why a busy database doing many tiny scattered writes often prefers RAID 10 (just two plain writes, no parity math) even though it gives up more capacity. The OS softens the blow the way it always does for a slow disk — it batches writes and lets the positioning cost amortise — but it cannot make the parity arithmetic disappear.

The rebuild problem nobody mentions

Here is the part the brochures skip, and the reason this guide is named the way it is. "Survives one disk failure" sounds like a finish line, but it is the start of the most dangerous window in the array's life. When a disk in a RAID 5 dies you are now running with NO redundancy — the parity that protected you is being spent to cover the gone disk. You slot in a fresh disk and the array begins a rebuild: it must read every block on every surviving disk and XOR them to reconstruct the dead disk's contents onto the new one. Until that finishes, a single further failure loses everything.

  1. A disk fails. The array goes degraded: it still serves data, but by reconstructing the missing disk's blocks on the fly, so it is slower and has no safety margin left.
  2. You replace the dead disk. The rebuild starts and must read EVERY block of EVERY surviving disk to recompute the lost one — a full, sustained sweep of the whole array.
  3. That sweep takes a long time on big drives. Copying an 8 TB disk's worth of data at disk speed runs for many hours, sometimes more than a day — and the whole time the array is unprotected.
  4. During those hours, every surviving disk is being read end to end under heavy load — exactly the stress most likely to expose a second weak disk, or a single unreadable sector that silently rotted while sitting idle.

Two things make this genuinely scary, and both got worse as disks got bigger. First, drives in an array are usually the same model from the same batch, bought together and worked equally hard — so when one dies of old age, its siblings are statistically primed to follow soon, and the rebuild's heavy reading is just the push. Second, disks have a small but real rate of unrecoverable read errors: a single sector that simply will not read back. On a one-off read you would never notice, but a rebuild must read every single sector of every surviving disk perfectly, and on a multi-terabyte array the odds of hitting even one bad sector during that full sweep stop being negligible. Hit one, and RAID 5 cannot finish the rebuild — the very moment you needed it.

This is precisely why RAID 6 (two parities, survives two failures) and mirroring/RAID 10 (rebuild reads only one surviving disk, not the whole array) overtook plain RAID 5 for large modern drives. And it loops us right back to the opening warning: even RAID 6 is about surviving disk DEATHS during a rebuild — it does nothing about deletion, corruption, or fire. The honest engineer's stance for storage is layered, like mass-storage design in general: choose a RAID level for the uptime you need and the rebuild risk you can stomach, AND keep real backups elsewhere, because redundancy and backup answer two different questions and neither one substitutes for the other.

Does RAID still matter on SSDs?

It is worth closing the rung honestly, because RAID was born in the spinning-disk era and the SSD changes some of its arithmetic. The redundancy story is unchanged: an SSD still dies, flash cells still wear out, so striping, mirroring, and parity protect you exactly as before, and the rebuild problem is just as real (arguably starker, since a bad batch of SSDs can hit their wear limits at nearly the same time). What shifts is the SPEED story. A single SSD is already so fast that striping for raw throughput matters far less than it did, and because an SSD has no seek time, the careful contiguous-layout games that made striped hard disks shine simply do not pay off the same way.

There is even a small tension worth naming. The parity small-write penalty means RAID 5 and 6 generate extra writes, and on flash extra writes mean extra wear — the very write amplification the SSD's own controller already fights. So the modern instinct, when the budget allows, leans toward mirroring or RAID 10 on SSDs: simpler, gentler on flash lifetime, and far quicker to rebuild. This mirrors the lesson from the disk-scheduling guide — that the SSD quietly knocked the legs out from under several spinning-disk-era cleverness's. The redundancy ideas survive the transition intact; the speed-oriented ones largely do not, because the cost they were fighting is gone.

Notice, finally, what RAID is at heart: an abstraction. It takes several flawed physical disks and hands the OS one virtual disk — faster, or safer, or both — that the file system can use without knowing how many real disks hide beneath it, much as logical block addressing hands software a flat array of blocks over a messy physical reality. That layering is the deep theme of this whole rung. Each layer hides the awkwardness below it and offers a cleaner surface above — and the price of every abstraction is the honest catch underneath it, which is exactly what an OS engineer is paid to keep in view.