{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

RAID workload and drive performance inputs
Compare RAID 0, 1, 5, 6, or 10 using the same drive and workload assumptions.
Mirror layouts require an even count; parity layouts enforce their minimum width.
drives
The model scales read service across every active member.
IOPS
Parity layouts consume more physical operations for small random writes.
IOPS
{{ percent(read_pct, 0) }} reads
%
Use the workload's typical transfer size, not the drive's advertised sequential block size.
KiB
{{ workflowFeedback }}
Use 100% until controller, queue, or alignment losses are supported by evidence.
%
This explicit holdback reduces both the headline IOPS and throughput budgets.
%
Enter 0 when no verified controller-side ceiling should be applied.
IOPS
This is separate from the built-in layout retention factors and should stay at zero without evidence.
%
{{ tableExportStatus.snapshot }}
MeasureValuePlanning meaningCopy
{{ row.measure }}{{ row.value }}{{ row.meaning }}
{{ tableExportStatus.constraints }}
CheckCurrent signalNext actionCopy
{{ row.check }}{{ row.signal }}{{ row.action }}
{{ chartExportStatus }}

Single-drive benchmarks do not become array performance by simple multiplication. Reads can spread across active members, but protected writes create extra back-end work. A small random write to mirrored storage must reach another copy; parity RAID may have to read old data and parity before writing both the new data and updated parity.

The workload mix decides how much that write cost matters. A read-heavy service can stay close to aggregate read capability, while a write-heavy service exposes the RAID penalty much more strongly. Average operation size adds another dimension because the same IOPS budget represents very different throughput at 4 KiB and 256 KiB.

Drive service rate
Active drives multiplied by a representative per-drive read or write benchmark.
Write penalty
Back-end operations charged to one modeled small random host write.
Efficiency and reserve
Explicit reductions for measured loss and operational headroom.
Controller ceiling
A known cap imposed by the controller, host bus adapter, fabric, appliance, or host path.

Parity penalties are planning conventions, not universal performance laws. Write-back cache, full-stripe writes, coalescing, queue depth, controller firmware, media latency, and workload locality can all change observed behavior. Reliable sizing starts from benchmarks that match the intended block size, access pattern, queue depth, and controller path.

A healthy-state estimate also says little about service during rebuild. Degraded operation may require reconstruction reads while recovery competes with foreground I/O. That is why a useful budget shows both a healthy allowance and a separate degraded scenario.

How to Use This Tool:

Use one internally consistent workload sample rather than mixing peak figures from unrelated tests.

  1. Select RAID level and enter the count of active data-serving drives. Dedicated hot spares do not contribute IOPS.
  2. Enter sustained per-drive random read and write IOPS measured at a representative block size and queue depth.
  3. Set Read share and Average operation size. The remaining percentage is treated as writes.
  4. Apply array efficiency, rebuild reserve, a verified controller ceiling, or additional degraded-write drag only when evidence supports them. Read Performance snapshot for the selected array and use the comparison view only for topologies that fit the same drive count.

Interpreting Results:

Safe modeled IOPS is the blended read/write estimate after efficiency, reserve, and any controller cap. It is a planning budget, not a guaranteed benchmark result.

  • Controller-limited means the media-side estimate exceeded the entered ceiling; adding drives does not raise the displayed healthy budget until that cap changes.
  • Degraded retention is the model's weighted fraction of healthy IOPS during degraded operation. It does not predict latency or rebuild completion time.
  • Comparison rows reuse the same drive rates, workload mix, efficiency, reserve, cap, and degraded drag. This makes the arithmetic comparable, but not necessarily the resulting real arrays.
  • RAID 0 has zero degraded output in this model because it has no protected degraded state.

Technical Details:

The model treats read and write service as separate paths, blends them by workload share, then applies explicit holdbacks. Values remain unrounded until they are displayed.

Formula Core

Read service scales with active drives. Write service also scales with drives but is divided by the selected small-random-write penalty.

Iread=N×Idrive readIwrite=N×Idrive writeP

Read share r is expressed as a ratio from 0 to 1. Efficiency e and reserve h are also ratios.

Ibefore cap=rIread+1-rIwrite×e×1-h

A positive controller ceiling is applied with a minimum function; zero disables the cap. Throughput uses the entered average operation size in KiB.

Isafe=minIbefore cap,IcontrollerT=Isafe×BKiB1024

Rule Core

The write penalties and degraded retention factors are fixed planning assumptions in this model.

RAID performance rule constants
LevelMinimum active drivesWrite penaltyDegraded read factorDegraded write factor
RAID 01100
RAID 12, even count20.880.58
RAID 5340.740.42
RAID 6460.700.36
RAID 104, even count20.820.52

Additional degraded-write drag reduces only the degraded write factor. The final degraded factor is read share multiplied by the level's degraded read factor plus write share multiplied by the adjusted degraded write factor. Degraded IOPS is safe IOPS multiplied by that factor.

Accuracy Notes:

  • The fixed write penalties represent small random writes. Cache, coalescing, full-stripe writes, SSD behavior, and controller design can change the observed cost.
  • The fixed degraded factors are declared scenario constants, not vendor guarantees.
  • Latency, queueing, cache hit rate, stripe size, alignment, CPU, network, protocol, filesystem, and application behavior are not modeled.
  • The displayed throughput label is MB/s, while the calculation divides KiB per operation by 1,024. Read it as a binary-scaled estimate and verify throughput with a representative benchmark.

Worked Examples:

Six-drive RAID 5 workload

Six drives rated at 200 read IOPS and 160 write IOPS, with a 60% read share, produce 1,200 read-service IOPS and 240 write-service IOPS after the RAID 5 penalty of 4. The blend is 816 IOPS. Applying 90% efficiency and a 10% reserve leaves 660.96 safe modeled IOPS, or 5.16375 on the displayed MB/s scale at 8 KiB per operation.

References: