Disk IOPS Calculator

How to use this disk IOPS calculator

1. Choose the calculation mode. Use RAID IOPS for arrays, IOPS ↔ throughput for unit conversion, or latency / queue depth for a concurrency estimate.
2. Match the measurement conditions. Block size, random or sequential pattern, read/write mix, queue depth, and steady state must represent the intended workload.
3. Calculate and inspect the arithmetic. Open “Show calculation” to see the exact substituted values, RAID penalty, cache assumption, and any applied cap.
4. Validate under stress. Benchmark with representative data, the application latency objective, controller and link limits, and degraded/rebuild operation.

Worked RAID IOPS calculations

Example 1: HDD RAID 10 database workload

Eight 10K HDDs at 140 random read and 140 random write IOPS per drive, RAID 10, 80% planning efficiency, 70% reads / 30% writes, 8 KiB blocks, a 300 IOPS target, and 20% design headroom.

• Raw read and write capability: 8 × 140 = 1,120 IOPS each.
• Read ceiling: 1,120 × 0.80 = 896 read IOPS.
• RAID-adjusted write ceiling: 1,120 ÷ 2 × 0.80 = 448 write IOPS.
• Blended front-end IOPS: 1 ÷ (0.70 ÷ 896 + 0.30 ÷ 448) = 689 IOPS.
• Back-end operations at that mix: 689 × (0.70 × 1 + 0.30 × 2) = 896 operations/s.
• Block-size throughput: 689 × 8 ÷ 1,024 = 5.38 MiB/s.
• Buffered demand: 300 ÷ (1 − 0.20) = 375 IOPS; four drives produce 345, while six produce 517, so the minimum valid RAID 10 layout is six drives.

Example 2: SSD RAID 5 mixed workload

Six SATA SSDs at the calculator’s conservative 4 KiB reference of 80,000 reads and 60,000 writes per drive, RAID 5, 85% efficiency, 70/30 mix, 4 KiB blocks, a 100,000 IOPS target, and 20% design headroom.

• Raw capability: 6 × 80,000 = 480,000 read IOPS and 6 × 60,000 = 360,000 write IOPS.
• Read ceiling: 480,000 × 0.85 = 408,000 IOPS.
• RAID-adjusted write ceiling: 360,000 ÷ 4 × 0.85 = 76,500 IOPS.
• Blended front-end IOPS: 1 ÷ (0.70 ÷ 408,000 + 0.30 ÷ 76,500) = 177,391 IOPS.
• Back-end operations: 177,391 × (0.70 × 1 + 0.30 × 4) = 337,043 operations/s.
• Block-size throughput: 177,391 × 4 ÷ 1,024 = 692.93 MiB/s.
• Buffered demand: 100,000 ÷ (1 − 0.20) = 125,000 IOPS; four drives produce 118,261, while five produce 147,826, so five drives are required.

Methodology and assumptions

This calculator uses the common small-block random I/O planning model for RAID write penalties. Random reads are treated as one physical read per logical read and can usually be served by any array member. Random writes on parity RAID require extra reads and writes to update parity, so RAID 5 uses a write penalty of 4 and RAID 6 uses a write penalty of 6. RAID 10 uses a penalty of 2 because each logical write is mirrored.

The mixed formula is a weighted service-capacity model: each host I/O consumes its fraction of the read ceiling or write ceiling. Adding those fractional capacity costs and taking the reciprocal produces the sustainable mixed rate. An arithmetic average would overstate capacity when writes are slower. Results are front-end host IOPS; back-end operations multiply reads by one and writes by the RAID penalty.

Sequential throughput is modeled separately because full-stripe writes and large requests behave differently from random IOPS. Input MB/s is decimal (1,000,000 bytes/s); workload MiB/s uses binary KiB and MiB. Cache-hit modeling increases the host-visible read ceiling but does not claim extra physical drive IOPS. The degraded/rebuild option is a documented 70% planning factor, not a platform-specific prediction.

Preset conditions: HDD assumptions represent small random single-request service at low queue depth and are not steady-state flash tests. SSD and NVMe assumptions are conservative, synthetic 4 KiB random estimates at queue depth 32 after warm-up/steady state, with separate read-only and write-only patterns; sequential values use large-block transfers. They are generic planning inputs created by Starlight Robotics, not sourced to or guaranteed by a drive vendor. Replace them with measurements for a specific model.

IOPS, throughput, latency, and measurement

What IOPS measures

IOPS counts completed storage operations per second; it does not describe how much data each operation carries or how long a request waits. Throughput measures bytes per second, while latency measures time per operation. A system can report high IOPS at a deep queue while individual requests wait longer.

Why block size and queue depth matter

At a fixed bandwidth, larger blocks mean fewer possible IOPS. Queue depth can expose device parallelism, so IOPS ≈ queue depth ÷ latency, but raising the queue can also increase response time. Compare measurements only when block size, access pattern, mix, queue depth, cache, test duration, and steady-state condition match.

How to obtain measurements

On Linux, use fio with an explicit rw, bs, iodepth, direct-I/O/cache choice, runtime, and steady-state criterion; observe achieved depth and latency percentiles. Use iostat -x to observe live operations, throughput, queueing, utilization, and await time. On Windows, Performance Monitor exposes Disk Transfers/sec, Disk Bytes/sec, and Avg. Disk sec/Transfer; DiskSpd can generate repeatable workloads with explicit block size, random/sequential access, outstanding I/O, cache mode, duration, and latency reporting. Test on expendable data and understand that write benchmarks can destroy data.

Why vendor peaks differ

Peak figures may use a favorable block size, read-only pattern, many queues, compressible data, fresh cache, or a preconditioned device at a different latency objective. Application performance also includes filesystem, encryption, virtualization, network, controller, background work, and tail-latency effects.

Short glossary

Front-end IOPS

Requests completed for the host or application.

Back-end operations

Physical array work after mirror or parity amplification.

Queue depth (QD)

Outstanding I/O requests kept in flight.

Steady state

A sustained test period where performance has stabilized.

MiB/s

Binary throughput: 1,048,576 bytes per second.

MB/s

Decimal throughput: 1,000,000 bytes per second.

References and limitations

• fio documentation — workload pattern, block size, I/O depth, latency, and steady-state controls.
• Microsoft DiskSpd — Windows storage workload generation and latency measurement.
• Microsoft drive performance history — mappings for IOPS, throughput, and latency counters.
• Microsoft RAID I/O capacity planning — mirrored I/O equations and the four-operation RAID 5 small-write model.
• NIST SI unit guidance and IEC binary prefixes — decimal MB and binary MiB distinction.

Limitations: this deterministic model does not simulate latency distributions, stripe alignment, full-stripe optimization, SSD endurance/garbage collection, deduplication or compression, tiering, network protocol overhead, filesystem allocation, or vendor-specific cache algorithms. Its figures are theoretical ceilings reduced into planning estimates by user assumptions and entered caps.

RAID write penalty reference

FAQs

What is a good IOPS number?

A good IOPS number is one that meets the application demand at its latency objective with design headroom. Media labels alone are not enough: block size, read/write mix, queue depth, cache state, and RAID layout must match the workload.

How do I calculate IOPS from MB/s?

Convert decimal MB/s to bytes per second and divide by bytes per operation: IOPS = MB/s × 1,000,000 ÷ block size in bytes. For example, 500 MB/s at 4 KiB is about 122,070 IOPS.

How do I calculate IOPS from latency and queue depth?

Use IOPS ≈ queue depth × 1,000 ÷ average latency in milliseconds. It is an upper-bound relationship when that queue depth is sustained; software, contention, and the device can lower the observed result.

How many IOPS do I need for a VM or database?

Measure peak front-end reads and writes at the application latency target, include growth and failure-mode demand, then add a design buffer. Generic per-VM or per-database figures are not reliable substitutes for workload measurements.

Does block size affect IOPS?

Yes. Larger operations consume more bandwidth, so the IOPS possible through a fixed link falls as block size rises. A drive’s 4 KiB random IOPS rating must not be assumed at 8 KiB or 1 MiB.

What are front-end and back-end IOPS?

Front-end IOPS are host requests. Back-end operations are the physical reads and writes generated by the array. Mirroring and parity can turn one host write into multiple back-end operations.

Do hot spares contribute IOPS?

No. A dedicated hot spare is idle during normal operation and should be excluded from active performance and usable capacity until it replaces a failed drive.

Why do real benchmarks differ from this estimate?

Real results depend on block size, random or sequential access, read/write mix, achieved queue depth, latency, cache and data reduction, SSD steady state, controller and link limits, filesystem, firmware, background work, and degraded or rebuild state.

Does cache change the RAID write penalty?

Cache and write coalescing can reduce observed penalties for bursts or full-stripe writes. The conventional penalty remains a useful conservative model for sustained small random writes after cache is exhausted.

How should I model degraded mode?

Enable the degraded or rebuild control to apply a conservative reduction, then validate on the actual platform. Reconstruction, rebuild traffic, and spare activation can reduce IOPS and make tail latency less consistent.

Is this calculator private?

Yes. Calculations run locally in the browser. Sharing a scenario only updates the page URL with the entered configuration.

Disclaimer

Use these results for sizing discussions and comparison, not as a production guarantee. Validate final storage designs against vendor documentation, benchmark data, application latency targets, cache settings, endurance limits, and backup or recovery requirements.