Most RAID explanations stop at "RAID 5 balances capacity and redundancy" and leave it there, which is true but not actually useful for deciding anything. The real decision comes down to three things pulling in different directions at once — usable capacity, fault tolerance, and write performance — and every RAID level is a specific compromise between them. Picking one out of habit, because it's what the last server used or what a forum thread recommended, skips the part where you actually decide which of those three you can afford to sacrifice for your specific workload.
The parity write penalty most explanations skip
RAID 5 and RAID 6 don't store a simple copy of your data the way mirroring does — they store parity, a value calculated from the other blocks in the stripe that lets a missing block be reconstructed mathematically. That calculation is exactly why parity RAID has a real, measurable write cost that mirroring and striping don't: a small write to a parity array typically has to read the existing data block, read the existing parity block, calculate the new parity, then write both the new data and the new parity back out — four I/O operations to satisfy what looks like a single write request, commonly called the RAID 5 write penalty.
This is the detail that separates "good balance of capacity and redundancy" from "wrong choice for this workload." A file server or media archive that's mostly sequential writes and occasional reads barely notices this penalty. A transactional database doing constant small random writes — order processing, a busy application backend, anything with a lot of concurrent short transactions — feels it directly, because every one of those small writes pays the four-operation cost. This is the concrete, measurable reason RAID 10 is the default recommendation for busy databases and RAID 5/6 isn't: RAID 10's mirrored pairs absorb a write as a straightforward duplicate to two drives, no parity recalculation involved.
The math behind why RAID 5 gets risky at large drive sizes
The claim "don't use RAID 5 with big drives" gets repeated often enough to sound like folklore, but it's based on an actual, calculable failure mode. Drives carry a spec for unrecoverable read error (URE) rate — how often, statistically, a bit can't be read back correctly. A commonly quoted figure for consumer-grade SATA drives is one unrecoverable error per 1014 bits read, which works out to roughly 12 terabytes; enterprise SAS drives are typically specified an order of magnitude better, around 1015.
Here's why that matters specifically during a RAID 5 rebuild: reconstructing a failed drive requires reading the entire surviving contents of every other drive in the array. A 4-drive array using 4TB consumer drives has to read roughly 12TB across the survivors to complete a rebuild — right at the threshold where a single-drive URE spec says an unrecoverable read error becomes a real statistical possibility, not a remote one. Hit that error mid-rebuild on a single-parity array and the rebuild fails outright, because there's no second parity copy to fall back on. This is precisely the scenario RAID 6 exists to survive: with two parity blocks per stripe, a URE encountered during rebuild after one drive has already failed doesn't take the whole array down with it. It's also why the drive size where this becomes a real concern keeps climbing as URE specs improve — the math scales with both drive capacity and the manufacturer's quoted error rate, not a fixed number that was ever meant to apply forever.
Why rebuild time keeps getting worse, not better
There's a second factor compounding the URE risk that's easy to miss: drive capacity has grown far faster than sustained sequential throughput. A drive's interface speed and internal transfer rate haven't scaled anywhere near as fast as areal density has, which means the time needed to fully read or write a drive's entire capacity — exactly what a rebuild has to do — has been steadily increasing for years, even as drives get labelled "faster" on other specs like random IOPS. A rebuild that took a few hours on smaller, older drives can genuinely stretch past 24 hours on today's large-capacity drives, and every one of those extra hours is more time the array spends with reduced or zero redundancy, and more time for a second failure or a URE to actually occur. This is the practical reason the size threshold where "just use RAID 6 instead" starts applying keeps drifting — it isn't a fixed capacity number, it's wherever your specific drives' rebuild time makes the failure window uncomfortably long for what you're storing.
RAID 10 vs RAID 6: a worked comparison
Take eight 4TB drives and compare the two most common choices for a workload that actually needs both performance and real redundancy. RAID 6 gives (8 − 2) × 4TB = 24TB usable, survives any two simultaneous drive failures, but carries the full parity write penalty on every random write. RAID 10 gives (8 ÷ 2) × 4TB = 16TB usable — a third less capacity — but writes go straight to mirrored pairs with no parity calculation, and a rebuild only has to re-mirror one surviving partner drive rather than read the entire remaining array.
Neither is objectively better; they're solving for different constraints. RAID 6 is the right call when capacity efficiency matters and the workload is more read-heavy or sequential — bulk storage, media, backups-to-disk, archives. RAID 10 is the right call when write performance and fast, low-risk rebuilds matter more than squeezing out every terabyte — busy OLTP databases, virtualization hosts running many VMs' worth of concurrent I/O, anything where a slow rebuild under production load is itself an operational risk.
Picking by workload instead of habit
A practical way to actually decide: identify whether the workload is dominated by random writes or by sequential reads/writes, and whether you can tolerate the capacity cost of mirroring or need parity's better efficiency. Random-write-heavy and latency-sensitive → RAID 10 despite the capacity cost. Capacity-sensitive with mostly sequential or read-heavy access → RAID 6 (or RAID 5 only on genuinely small, well-monitored arrays with modern low-URE drives). Nothing you'd be upset to lose, or a pure scratch/cache volume → RAID 0 is honestly fine, precisely because there's nothing at stake.
One cheap mitigation worth building into any parity array regardless of which level you land on: a hot spare, sitting idle and ready to rebuild onto automatically the moment a failure is detected, shrinks the window between failure and rebuild start from however long it takes a human to notice and act down to effectively zero — and given how much the rebuild-time math above depends on minimizing total exposure time, cutting the detection delay matters as much as the rebuild duration itself. And regardless of which level you land on: RAID protects against a drive failing, not against ransomware, accidental deletion, or the controller itself dying — it has never been a substitute for an actual backup, and treating it as one is a separate mistake from picking the wrong level in the first place.