Hard Disk IOPS Calculator for HDD Arrays

Sure, you bought those hard drives because they held so much stuff. They was supposed to hold three hundred gigs of old photos, or maybe five terabytes of video. That’s why you bought them, that was the selling point.

But then you go to run a virtual machine off that array, and holy crap, does it grind to a halt. It’s not because there isn’t enough space, it’s because there aren’t enough IOPS (input operations per second). And unlike space, IOPS is tiny on spinning rust versus flash storage. And that IOPS number dictates whether your server feel snappy or sluggish.

Why Hard Drives Are Slow With Random Data

But real world physics apply to a hard disk; every random read has to move the actuator arm to the new track, then wait until the platter rotates back around so it can reach actual data. The sum of seek time + rotational latency = service time. A typical 7200 RPM drive could take up to ten milliseconds to locate a single little block of data. Do the math, you’ll see that at most your disk will be able to handle about one hundred operations per second before it’s fully saturated. Most folks dramatically overestimate what their few random writes does with that budget.

There’s another sneaky tax on this performance: RAID levels. While adding redundancy with parity protection is great, in a RAID five configuration, it means a single small write can require quadruple the effort. If your RAID level is five, then a little tiny write can become four physical writes (read old data, read old parity, calculate new parity, write new data). This is a killer of throughput.

When you pick out your layout, the calculator above will tell you exactly how many spindles you need to cover this overhead. Ignore the overhead and you’ll purchase storage that may look big but will perform poor under a load.

Hard drives are terrible at handling multiple requests simultaneously; that’s where queue depth comes into play. The more commands it receives from your workload in parallel, the longer it take to switch between them and the less time it has working; this is why the queue will cause latency spikes. A small queue maintains consistent latency for random workloads (think: virtual machines or databases). Higher queues, meanwhile, maintain throughput for sequential data streams such as media playback. The catch: know what kind of workload you’ve got. Table on the page shows this clearly by scenario. Backup target vs. NAS).

Read-heavy situations will get a boost from cache hits: The IOPS cost will drop nearly to zero if the controller or operating system can serve the request directly from memory (RAM) vs. The system has to spin up the disk. You’ll see this matter most in repeated access patterns. Caching is huge for a photo library that’s going to be viewed over and over again; it doesn’t do much for a surveillance camera, which writes new unique video frames every second. The calculator lets you tweak the hit rate to account for this, and it gives more realistic picture of how the host will perform vs. The raw limits of those spindles.

With sequential workloads, it’s a different story. Because data comes in big blocks, there isn’t much seeking for the drive. It simply continues writing at full speed until it has filled its cylinder. So while hard drives struggle with low IOPS, they shine during sequential workloads. You’re transferring large files and your workload is largely sequential, so you don’t care about operations per second; rather, you care about megabytes per second. These two mixed together make a complicated blend. Separating the random IOPS burden from the sequential throughput help you see which factor is limiting your performance.

There are always trade offs when building an HDD array. You must pick two from density, redundancy, or speed. For example, if you set up a RAID ten mirror stripe, you get great read performance and ok write performance, but you lose half of the capacity due to mirroring. On the other hand, if you use a RAID six array, you get double parity safety on a large array, but small writes will be painfully slow. The math doesn’t lie; you don’t get something for nothing. You should of known that.

You don’t want a theoretical max; you just want something you know is sustainable. You want some headroom so that when people do spike, there’s no buildup in the queue. Latency beyond twenty milliseconds starts getting perceptible to the user. If you understand the RAID penalties and the mechanical constraints of the disks, you can properly size an array for your workload rather than going purely based off a capacity basis. Make sure your data’s pattern matches how the disk work.