Need the fastest path to a number? Here it is:

  • Quick write test: dd if=/dev/zero of=./testfile bs=1M count=1024 oflag=direct
  • Quick read test: sudo hdparm -Tt /dev/sda
  • Serious benchmark: use fio with a test file larger than your RAM

Use dd for a sanity check, hdparm when you want a fast read number, and fio when you actually care about the result. That last one is the only tool to trust on a production-grade Linux VPS hosting box. Whether you're a system administrator, a power user, or someone hosting a Linux VPS, disk speed directly affects your application's performance, boot time, and data transfer efficiency.

Dark hero card listing Linux disk speed test quick picks: dd, hdparm, fio, and GNOME Disks.

Why Run a Linux Disk Speed Test?

Disks are often the silent bottleneck. CPU and RAM get the spotlight, but a slow disk drags everything down — boot times, database queries, container builds, even SSH responsiveness if I/O wait pegs the kernel. Running a disk speed test in Linux helps you understand:

  • How fast your storage device reads and writes data
  • Whether your disk is underperforming
  • If your SSD/HDD is suitable for workloads like gaming, databases, or media rendering
  • Whether your disk is becoming a bottleneck in server environments

I run a benchmark in three situations: when a server feels sluggish for no obvious reason, when comparing two hosting plans before I migrate, and after any storage change (new SSD, RAID rebuild, kernel upgrade). The numbers don't lie. Vibes do.

Before You Benchmark: Don't Skip This

This is the part most tutorials gloss over, and it's where people get into trouble. A bad benchmark is worse than no benchmark — you'll act on numbers that don't reflect reality.

Find the correct disk first

Running a write test against the wrong device can wipe data. Always confirm what you're touching:

lsblk
df -h
sudo fdisk -l

lsblk shows the tree of block devices and mount points. df -h tells you which filesystem is mounted where. If /dev/sda is your boot disk and /dev/nvme0n1 is the data volume, you want to be very sure which one your command is hitting.

Stylised terminal illustration of lsblk output showing /dev/sda and /dev/nvme0n1 with disk columns.

Don't benchmark production disks during peak hours

Synthetic load on a live server can spike latency for real users. If you must test in production, do it on a dedicated test file inside a filesystem you control — never against a raw block device that holds live data.

Beat the cache

Linux loves to cache. If your test file fits in RAM, you're benchmarking memory, not disk. Two rules:

  • Make the test file at least 2× your system RAM
  • Use oflag=direct with dd or --direct=1 with fio to bypass the page cache

You can also drop caches between runs with sync; echo 3 | sudo tee /proc/sys/vm/drop_caches. Run any benchmark three times and average the results. One run is noise.

What Actually Matters: Throughput, IOPS, Latency

Three numbers tell the story. Most tutorials only show one.

Metric What it measures Matters most for
Throughput (MB/s) Bulk data movement Video, backups, large file transfers
IOPS Small operations per second Databases, VMs, web apps
Latency (ms or µs) Time per operation Real-time apps, interactive workloads

An NVMe drive that pushes 5 GB/s sequential can still feel slow if its random 4K latency is poor. That's why a single MB/s number is misleading. Databases live and die on IOPS and latency, not throughput.

Command Line Tools That Actually Work

dd — the quick-and-dirty write test

dd is a versatile Unix command that can quickly test write performance by writing a dummy file:

dd if=/dev/zero of=./testfile bs=1M count=2048 oflag=direct
rm ./testfile

This writes 2 GB of zeros and reports MB/s. The oflag=direct bit skips the page cache. Explanation of flags:

  • if=/dev/zero: generates zero-filled blocks
  • of=testfile: target file to write to
  • bs=1M count=2048: writes 2048 blocks of 1 MB each (2 GB total)
  • oflag=direct: bypasses the page cache for more accurate measurements

Using dd – Simple Write Speed Test

💡 Ideal for testing sequential write speeds. Limitations? It only measures sequential write with a single thread. Don't quote dd numbers in a capacity-planning meeting.

hdparm — fast read check

This is one of the most common and accurate methods for checking disk read performance:

sudo hdparm -Tt /dev/sda

Using hdparm – Read Speed Test

  • Buffered Disk Reads (-t): Direct read from disk to RAM — this is what you want
  • Cached Reads (-T): Read from the buffer cache (RAM) — basically memory speed, ignore it

📊 Output includes MB/s speeds, useful for quick comparisons between drives. hdparm is showing its age on NVMe though; treat it as a rough indicator, not a verdict.

fio — the real benchmark

fio is an industry-standard disk benchmark utility that simulates real-world workloads. It's especially useful for developers and system administrators. If you only learn one tool, learn fio. Install it:

# Ubuntu / Debian
sudo apt install fio

# Arch Linux
sudo pacman -S fio
Stylised dark terminal infographic of fio random read output showing BW, IOPS, clat, and 99th percentile latency.

fio Benchmark Examples

Sequential read — large file transfers, media streaming:

fio --name=seqread --rw=read --bs=1M --size=4G --numjobs=1 \
  --iodepth=16 --ioengine=libaio --direct=1 --runtime=30 --group_reporting

Sequential write — backups, bulk loads:

fio --name=seqwrite --rw=write --bs=1M --size=4G --numjobs=1 \
  --iodepth=16 --ioengine=libaio --direct=1 --runtime=30 --group_reporting

Random read (4K) — databases, web apps:

fio --name=randread --rw=randread --bs=4k --size=4G --numjobs=4 \
  --iodepth=32 --ioengine=libaio --direct=1 --runtime=30 --group_reporting

Random write (4K) — transactional workloads:

fio --name=randwrite --rw=randwrite --bs=4k --size=4G --numjobs=4 \
  --iodepth=32 --ioengine=libaio --direct=1 --runtime=30 --group_reporting

Mixed 70/30 — realistic server load:

fio --name=mixed --rw=randrw --rwmixread=70 --bs=4k --size=4G \
  --numjobs=4 --iodepth=32 --ioengine=libaio --direct=1 --runtime=60 --group_reporting

In the output, look at three lines: BW (bandwidth), IOPS, and the clat (completion latency) percentiles. The 99th-percentile latency is usually what kills real-world performance.

GUI Tools for When You Don't Want a Terminal

Not everyone loves the terminal. If you prefer graphical tools for your Linux disk speed test, here are some options:

GNOME Disks

GNOME Disks ships with most desktop distros. Most GNOME-based Linux distros have the "Disks" utility built-in:

  • Open the app
  • Select a disk
  • Click the menu and choose "Benchmark Disk"
  • Press "Start Benchmark"

It shows both read/write performance and access time, great for basic users and sysadmins alike. Fine for laptops and quick checks.

KDiskMark

Inspired by Windows's CrystalDiskMark, KDiskMark offers a GUI for Linux disk speed testing. It's actually a friendly wrapper around fio, so the numbers are trustworthy. It's available in most major repositories. To install on Ubuntu:

sudo add-apt-repository ppa:jonmagon/kdiskmark
sudo apt update
sudo apt install kdiskmark

KDiskMark allows sequential/random read-write tests with graphical charts.

Stylised dark GNOME Disks benchmark panel with Read Rate, Write Rate, and Access Time graphs for an NVMe drive

Expected Speeds by Drive Type

Rough ranges — controller, firmware, and PCIe generation all swing these numbers:

Drive type Sequential read/write Random 4K IOPS
HDD (7200 RPM) 80–200 MB/s 75–200
SATA SSD 400–550 MB/s 20,000–90,000
NVMe (Gen3) 1.5–3.5 GB/s 200,000–500,000
NVMe (Gen4/5) 5–14 GB/s 500,000–1.5M+

If your SATA SSD is benchmarking at 150 MB/s, something's wrong — bad cable, SATA II port, or a failing drive. Run smartctl.

Reading Your Results Without Fooling Yourself

A few honest truths learned the hard way:

  • A great dd number doesn't mean your database will be fast. dd tests one thread, sequential, large blocks. Databases do the opposite.
  • If hdparm -T shows 10 GB/s, you're reading cache. Ignore it.
  • Cloud disks have burst credits. Your first 30 seconds look great, then performance collapses to the baseline. Run a 5-minute test before you trust the number.
  • Run every benchmark at least three times and discard the first run.

Disk Speed on a VPS or Cloud Server

VPS storage is weird. You might be on local NVMe one minute and network-attached storage the next, depending on the provider. Noisy neighbors on shared hosts can swing your IOPS by 50% between runs. That's not your benchmark lying — it's the underlying reality. In high-demand environments like cloud servers or Linux VPS Hosting, disk speed becomes even more critical. Use fio or ioping to evaluate:

  • IOPS (Input/output operations per second)
  • Latency
  • Throughput

Example ioping command:

sudo ioping -c 10 /mnt/data

For database-heavy workloads, IOPS matters more than throughput. If you're seeing high I/O wait on top or iostat, and random 4K IOPS are below ~10,000, your storage tier is the bottleneck. That's usually the moment to look at NVMe-backed Linux VPS hosting rather than older SATA SSD plans.

Troubleshooting Slow Disk Performance

Numbers came in low? Work through this list before blaming the hardware:

  • SMART health: sudo smartctl -a /dev/sda — check reallocated sectors, pending sectors, and wear leveling.
  • Live I/O: iostat -xz 2 shows per-device utilization and await time. High %util with low throughput means contention.
  • Latency probe: ioping -c 10 /mnt/data gives you a quick latency reading.
  • Free space: SSDs slow down dramatically above 85% full. Check df -h.
  • Thermal throttling: NVMe drives without heatsinks throttle hard under sustained load. Check nvme smart-log /dev/nvme0.
  • Background jobs: RAID rebuilds, backups, and cron jobs can eat all your I/O. Check iotop.

Real-World Use Cases for Disk Speed Testing

  • Web Hosting: Evaluate disk speed for better CMS performance
  • Game Servers: Low latency read/write is key
  • Database Hosting: High IOPS is critical for fast queries
  • Rendering & Media: Need fast throughput for large files

Need even faster performance? Learn how to push CPU performance too with our CPU Benchmark Software guide.

Tool Comparison Cheat Sheet

Tool Best for Measures Interface
dd Quick write sanity check Sequential write MB/s CLI
hdparm Quick read check Sequential read MB/s CLI
fio Serious benchmarking Throughput, IOPS, latency CLI
GNOME Disks Desktop / casual Read, write, access time GUI
KDiskMark Visual fio frontend Same as fio GUI

Conclusion

Whether you're trying to test disk speed for troubleshooting, benchmarking, or upgrading your infrastructure, the right tools are already available to you both in the terminal and in the GUI. Performing regular disk benchmarks helps you spot performance drops early and optimize your system's storage for real-world performance.

Pick the tool that matches your goal. Quick gut check? dd or hdparm. Real engineering decision? fio, every time. Visual report for a client or your own desktop? GNOME Disks or KDiskMark. And if your benchmarks keep coming back disappointing despite a healthy drive, the storage tier itself might be the ceiling that's usually when it's time to move from shared SATA to an NVMe-backed plan. Explore our Linux VPS Hosting solutions designed for speed, reliability, and scalability.

People also read: