Sequential vs Random I/O Performance on a 7‑Disk RAID5 Array: Benchmarks and Insights

Everyone knows that random I/O on hard disks is slow, but this article quantifies exactly how much slower it is compared to sequential I/O by running a series of fio benchmarks on a RAID5 array composed of seven 300 GB 7200 RPM mechanical disks.

Test setup : The tests use libaio with direct I/O, unified read/write reporting, a 300 s runtime, a 100 GB test file, noop scheduler, disabled disk cache, and refill_buffers to ensure true randomness. RAID prefetch is toggled between NORA (off) and RA (on). I/O sizes range from 512 B to several megabytes.

Sequential read results : Bandwidth is under 20 MB/s for small I/O sizes but climbs to over 1.2 GB/s as the size grows. A sharp bandwidth jump occurs when the I/O size exceeds the RAID strip size (128 KB), allowing the array to parallelize across disks. With RAID prefetch enabled, the bandwidth reaches 1.2 GB/s already at 64 KB. Latency stays low (tens of microseconds) because most requests hit the RAID cache. IOPS peak at more than 30 k when the I/O size matches a single sector, then decline as size increases while throughput rises.

Random read results : Bandwidth collapses to a few hundred kilobytes per second for small I/O sizes, and latency rises to around 5 ms, matching the mechanical seek time. IOPS drop dramatically to roughly 200 ops/s, confirming that random access defeats both RAID caching and parallelism.

Key observations :

Sequential I/O benefits from high RAID cache hit rates and the ability to utilize the full strip width.

Random I/O forces the RAID cache to become ineffective and incurs full seek delays.

Increasing the I/O unit size improves performance for both patterns, but the effect is far more pronounced for sequential access.

Practical implications :

When copying directories with many small files, compress them into a single archive first so the copy becomes sequential I/O.

Database systems write transaction logs (sequential I/O) instead of updating data pages directly (random I/O) to achieve higher throughput.

MySQL uses B+‑tree indexes with relatively large nodes because larger I/O units align better with disk characteristics, improving read performance.

Real‑world case study : By loading an entire user table (millions of rows) into memory and using a hash table for lookups, a system reduced query latency by over 90 % compared to issuing millions of random MySQL reads.

Overall, the benchmarks demonstrate the stark contrast between sequential and random I/O on mechanical RAID arrays and provide concrete guidance for system design and performance tuning.