Where the write penalty comes from
A parity RAID set stores redundancy as a computed value, and that value has to stay consistent with the data. When an application writes a single block that is smaller than a full stripe, the controller cannot simply overwrite it. It must read the old contents of that block, read the old parity, compute the new parity from the difference, then write both the new data and the new parity. Four physical operations for one logical write. That is the RAID 5 penalty, and it is arithmetic, not an implementation weakness.
RAID 6 keeps two independent syndromes, so the sequence becomes read data, read P, read Q, write data, write P, write Q — six operations. RAID 1 and RAID 10 keep a whole copy rather than a computed value, so a write goes to both members: two operations. RAID 0 keeps nothing and writes once.
Reads are unaffected. A read touches one drive on any parity level, and on a mirror it can be served by either member, so the penalty applies to writes alone. This is why the read/write mix matters as much as the RAID level: a 95%-read reporting database barely notices RAID 6, while a 30%-read transaction log is crushed by it.
Front-end IOPS is what the application, hypervisor or virtual disk asks for. Back-end IOPS is what the physical devices must deliver. The whole point of this calculation is that the second number is the one your drive count has to satisfy, and on a write-heavy parity workload it can be several times the first.
The blended multiplier and what a drive can actually do
Split the workload, penalise the writes, add them back: back-end = F·r + F·(1−r)·P. Dividing through by F gives the blended multiplier r + (1−r)P, which is the single number worth remembering. At 70% reads on RAID 5 it is 0.7 + 0.3×4 = 1.9. At 50% reads on RAID 6 it is 0.5 + 0.5×6 = 3.5. At 100% reads it is 1 on every level.
Sizing the drive count needs a realistic figure for what one device delivers under random load. For spinning disks that figure is derivable rather than mysterious. A random operation costs an average seek plus half a rotation. A 15,000 rpm drive turns once every 4 ms, so average rotational latency is 2 ms; add a typical 3.4 ms average seek and you get 5.4 ms per operation, or about 185 IOPS. A 10,000 rpm drive: 3 ms rotational plus about 4.5 ms seek gives 7.5 ms, near 133 IOPS. A 7,200 rpm drive: 4.17 ms rotational plus about 8.5 ms seek gives 12.7 ms, near 79 IOPS. Those are the 180, 140 and 80 figures in the drive-type list, and they are why mechanical IOPS have barely moved in twenty years while capacities have grown a thousandfold.
Flash breaks the model completely because there is no seek and no rotation, so its random rate is set by the controller, the channel count and the flash-management overhead. Manufacturer figures for enterprise SSDs run from tens of thousands to over a million IOPS, and the useful number is the steady-state random figure after the drive's spare area is exercised, not the burst number on the front of the datasheet.
Finally, apply a utilisation target. A device driven to 100% of its rated random rate has a queue, and a queue is latency. Sizing to 70–80% of the rated figure is the normal convention and is what keeps response times inside the few-millisecond band that transactional applications need.
Worked example: 5,000 IOPS at 70/30 on 15k SAS
A database platform needs 5,000 front-end IOPS at a 70/30 read-write mix. The array uses 15,000 rpm SAS drives and you are considering RAID 5 with an 80% utilisation target.
- Split the workload. Reads: 5,000 × 0.70 = 3,500 IOPS. Writes: 5,000 × 0.30 = 1,500 IOPS.
- Penalise the writes. RAID 5 costs 4 operations per write: 1,500 × 4 = 6,000 back-end IOPS.
- Total the back end. 3,500 + 6,000 = 9,500 IOPS at the drives.
- Read off the multiplier. 9,500 ÷ 5,000 = 1.9×. Writes are 30% of requests but 6,000 ÷ 9,500 = 63% of the disk load.
- Set the usable rate per drive. 180 × 0.80 = 144 IOPS each.
- Divide and round up. 9,500 ÷ 144 = 65.97, so you need 66 drives.
- Check the alternatives. RAID 10 has a penalty of 2, giving a multiplier of 0.7 + 0.3×2 = 1.3 and a back end of 6,500 IOPS, which needs 46 drives. RAID 6 has a penalty of 6, a multiplier of 2.5, 12,500 back-end IOPS, and 87 drives.
- Convert to throughput. At an 8 KiB average request size, 5,000 IOPS is 5,000 × 8 × 1,024 ÷ 106 = 41 MB/s at the front end — trivial for the fabric, which confirms this workload is IOPS-bound rather than bandwidth-bound.
The interesting comparison is step 7. Moving from RAID 5 to RAID 10 cuts the drive count by 20 while halving usable capacity, and moving to RAID 6 costs 21 more drives while adding a second parity. Which trade is right depends on whether the array is capacity-bound or IOPS-bound, and the honest way to decide is to size both ways — here and in the RAID capacity calculator — and take the larger drive count.
How to read the result
The blended multiplier tells you whether the RAID level is worth arguing about. Below about 1.3 the layout barely matters and you should choose on capacity and rebuild behaviour. Above 2.5 the layout is dominating your drive count, and moving to a mirror or adding a write-back cache will change the answer more than adding spindles.
Negative headroom is a hard failure, not a warning. If the proposed drive count delivers fewer front-end IOPS than the requirement, the array will queue and latency will rise until the application times out. Size to the requirement plus a real margin, because a rebuild, a background scrub and a snapshot consolidation all consume back-end IOPS that your workload calculation never saw.
On flash, treat the arithmetic as an upper bound. A handful of NVMe devices can satisfy hundreds of thousands of IOPS on paper, at which point the bottleneck moves to the controller CPU, the HBA queue depth, the fabric or the filesystem. The calculation remains useful for showing that the media is not the constraint; a benchmark is what tells you where the constraint moved to.
Throughput and IOPS are different limits and both apply. A 5,000 IOPS workload at 8 KiB is 41 MB/s; the same 5,000 IOPS at 256 KiB is 1.3 GB/s, which will saturate a single 10 Gb link. Check the MB/s figure against your fabric before you assume the drive count is sufficient.
Capacity and performance sizing rarely agree. Do both, take the larger drive count, and note which constraint won — because when the workload changes, the constraint often changes with it.
Write penalty and device performance reference
| RAID level | Write penalty | Multiplier at 70% reads | Multiplier at 30% reads |
|---|---|---|---|
| RAID 0 | 1 | 1.00 | 1.00 |
| RAID 1 / 10 | 2 | 1.30 | 1.70 |
| RAID 5 / 50 | 4 | 1.90 | 3.10 |
| RAID 6 / 60 | 6 | 2.50 | 4.50 |
| Device | Rotational latency | Typical seek | Random IOPS |
|---|---|---|---|
| 7,200 rpm SATA / NL-SAS | 4.17 ms | ~8.5 ms | ~80 |
| 10,000 rpm SAS | 3.00 ms | ~4.5 ms | ~140 |
| 15,000 rpm SAS | 2.00 ms | ~3.4 ms | ~180 |
| Consumer SATA SSD | — | — | 5,000-20,000 sustained |
| Enterprise SATA SSD | — | — | 20,000-60,000 |
| Enterprise NVMe SSD | — | — | 100,000-1,000,000 |
Rotational latency is half a revolution: 30,000 ÷ rpm milliseconds. Adding the seek gives the service time, and its reciprocal is the IOPS figure. Flash IOPS are steady-state ranges from vendor datasheets and vary widely by model.
When the penalty does not apply in full
Controllers work hard to avoid the read-modify-write cycle. A write-back cache can coalesce several small writes into one full-stripe write, for which parity is computed from the new data alone and no reads are needed — that reduces the effective penalty substantially for sequential and bursty write patterns. Some arrays also use a read-modify-write shortcut that reads only the affected data and parity blocks rather than the whole stripe, which is what gives RAID 5 its penalty of 4 rather than n+1. Log-structured and copy-on-write systems — ZFS RAID-Z, and most all-flash arrays — sidestep the penalty entirely by always writing full stripes to fresh space, at the cost of garbage collection later. Treat the penalty figures here as the worst case for small random writes, which is exactly the case that sizing must survive.
Assumptions and limits
- It models small random I/O. Full-stripe and sequential writes avoid most of the penalty, so a backup or bulk-load workload is far cheaper than this arithmetic suggests.
- Cache is not modelled. A well-sized write-back cache absorbs bursts and coalesces writes; the calculation here is the steady-state figure once cache is saturated, which is the number that matters at peak.
- Rebuild and scrub load is not included. A rebuilding array is reading every surviving member at full rate. If your headroom is 10%, a rebuild will be felt by users.
- Queue depth affects the per-drive figure. A drive delivering 180 IOPS at queue depth 1 may deliver more at depth 32 with NCQ reordering, but at higher latency. Use the figure measured at the latency you can tolerate.
- Snapshots, dedupe and compression change the mix. Inline data reduction adds CPU cost and can turn a sequential write into a random one; array vendors' own sizing tools account for their specific implementation and yours will not.
- It sizes for IOPS only. Run the same drive set through the RAID capacity calculator and take whichever count is larger.
Sizing in practice: measure first, then calculate
The weakest input in this calculation is the front-end IOPS requirement, and it is the one people guess. Measure it instead. On VMware, esxtop's disk device view gives commands per second per device. On Windows, Perfmon's Disk Transfers/sec with % Disk Read Time gives both the rate and the mix. On Linux, iostat -x gives reads and writes per second alongside average request size and service time. Take the 95th percentile over a working week, not the average, and note the average request size at the same time — you need both for this page.
Latency is the acceptance criterion, not IOPS. A well-sized transactional array delivers reads in single-digit milliseconds on spinning media and well under a millisecond on flash. If measured latency is high while IOPS are below your calculated ceiling, the problem is usually queue depth, a misaligned partition, or a single hot LUN rather than a shortage of spindles.
Two structural changes beat adding drives when the multiplier is high. Moving write-heavy volumes to a mirrored layout drops the penalty from 4 or 6 to 2. Moving them to flash removes the seek entirely and makes the penalty almost irrelevant, because a device delivering 30,000 IOPS can absorb a 6× multiplier without noticing. Both are usually cheaper than doubling a spinning array.
Once the array is sized, the remaining questions are how much of it you can write to — the RAID capacity calculator — how often it will be unavailable, which the MTBF, MTTR and availability calculator quantifies from drive failure rates and replacement times, and whether the network in front of it can carry the resulting throughput, which the Mbps to MB/s converter makes directly comparable.