Testing disk speed in Linux sounds simple until the results start behaving like a cat near a bathtub: unpredictable, dramatic, and somehow your fault. One command says your SSD writes at 900 MB/s. Another says 240 MB/s. A third insists everything is fine while your database feels like it is walking through peanut butter. Welcome to Linux disk benchmarking, where the numbers are useful only when you understand what they actually measure.

This guide explains how to test disk speed in Linux using practical tools such as dd, fio, hdparm, iostat, GNOME Disks, and KDiskMark. You will learn how to check sequential read and write speed, random I/O performance, latency, IOPS, and real-time disk activity. More importantly, you will learn how not to accidentally benchmark your cache, your RAM, or your own patience.

What “disk speed” really means in Linux

Before running commands, it helps to know what you are measuring. Disk speed is not one single number. It is a small family reunion of metrics, and some relatives are more useful than others depending on your workload.

Sequential read and write speed

Sequential speed measures how fast a drive can read or write large continuous chunks of data. This matters for copying big files, video editing, backups, disk imaging, and moving virtual machine images. If you are transferring a 40 GB movie file, sequential throughput is the number you care about.

Random read and write performance

Random performance measures how well a disk handles many small operations scattered across the storage device. This matters for databases, web servers, virtual machines, software development folders, package managers, and anything that creates many tiny files. A drive can have impressive sequential speed and still feel sluggish when random I/O is weak.

IOPS

IOPS means input/output operations per second. It tells you how many read or write operations the storage device can complete in one second. Small random 4K operations are commonly used to estimate IOPS because they resemble many real application workloads.

Latency

Latency is the time it takes for a single I/O request to complete. Low latency makes a system feel responsive. High latency makes every click feel like the computer is thinking about its life choices.

Before you test: avoid fake numbers and sad accidents

Linux aggressively uses memory for caching. That is good for performance, but it can trick simple benchmarks. If your test file is too small, Linux may serve much of the data from RAM instead of the disk. Congratulations: you just benchmarked your memory and gave your SSD undeserved applause.

Use a test file larger than your available RAM when possible, or use tools that support direct I/O, such as fio. Run benchmarks when the system is mostly idle. Close heavy applications, stop large downloads, and avoid testing during backups, updates, or database maintenance.

Also, do not run write benchmarks directly against a device such as /dev/sda, /dev/nvme0n1, or any disk containing important data unless you know exactly what you are doing and have backups. This guide focuses on safer file-based tests inside a mounted directory.

Check your disks first

Start by identifying your storage devices and mount points:

The lsblk command shows block devices, partitions, filesystems, and mount points. The df -h command shows available space in human-readable form. Pick a directory on the disk you want to test, such as /home, /mnt/data, or a mounted external SSD.

For example, if /mnt/storage is mounted on the drive you want to test, run your benchmark commands from that directory:

Method 1: quick write speed test with dd

The dd command is available on almost every Linux system. It is not the most complete benchmark tool, but it is useful for a quick sanity check. Think of it as the pocket flashlight of disk testing: not fancy, but handy when the lights go out.

Run this safe file-based write test:

This writes a 4 GB file named testfile.img. The oflag=direct option helps bypass the page cache, making the result closer to actual disk write performance. The status=progress option shows progress while the command runs.

Remove the test file afterward:

You can also test write performance with synchronization:

The conv=fdatasync option tells dd to physically write output file data before finishing. This prevents the command from ending too early while data is still waiting in cache.

When dd is useful

Use dd when you need a fast estimate of large-file write speed. It is simple, common, and easy to run over SSH. However, it does not provide detailed latency, random I/O, queue depth, or mixed workload results.

When dd is misleading

dd can produce overly optimistic or overly narrow results. By default, it uses a simple workload and may not push modern SSDs, NVMe drives, RAID arrays, or cloud block storage hard enough. For serious testing, use fio.

Method 2: test read speed with hdparm

The hdparm utility can measure read performance from a block device. It is especially useful for quick sequential read checks. Install it if your distribution does not already include it:

Find your disk name with lsblk, then run:

Replace /dev/sda with the correct device. For NVMe storage, it may look like this:

The -T result shows cached reads, which are mostly about memory and system cache performance. The -t result shows buffered disk reads and is more useful for estimating sequential disk read speed.

Run the command two or three times on an idle system and compare the results. If numbers swing wildly, another process may be using the disk, the drive may be thermal throttling, or power management may be interfering.

Method 3: serious Linux disk benchmarking with fio

If you want accurate disk speed testing in Linux, fio is the grown-up tool in the room. It can simulate sequential reads, sequential writes, random reads, random writes, mixed workloads, queue depth, multiple jobs, runtime limits, block sizes, and direct I/O. In other words, it does not just ask, “How fast is this disk?” It asks, “Fast at what, under what pressure, and while wearing which tiny performance hat?”

Install fio:

Sequential write test with fio

This test writes large 1 MB blocks for 60 seconds using direct I/O. The result will show bandwidth, IOPS, and latency statistics. Sequential write speed is useful for large transfers, backups, and media workloads.

Sequential read test with fio

After creating a test file, run:

This checks large-block read throughput. For a modern NVMe SSD, sequential read results may be very high. For an old laptop hard drive, the result may politely remind you that spinning rust has feelings too.

Random read test with fio

This test uses 4K random reads, a common way to evaluate responsiveness for databases, virtual machines, and application workloads. Look closely at IOPS and latency, not only bandwidth.

Random write test with fio

Random writes are often more demanding than random reads. On SSDs, performance may drop after the drive’s cache fills. On cloud volumes, results may depend on provisioned IOPS, burst credits, instance limits, and network storage conditions.

Mixed read/write test

This simulates a workload with 70% reads and 30% writes. Mixed tests are useful because real systems rarely do only one kind of I/O. Your web app, database, logging service, and package updater are all politely fighting for the same storage elevator.

How to read fio results

fio output can look intimidating at first, but the key fields are manageable:

• bw: Bandwidth, usually shown in KiB/s, MiB/s, or GiB/s.
• iops: I/O operations per second.
• clat: Completion latency, or how long I/O requests take to finish.
• lat percentiles: Latency distribution, including 95th, 99th, and sometimes 99.9th percentile values.
• iodepth: How many I/O requests are in flight at once.

Average latency is helpful, but percentile latency is often more revealing. A disk with a good average but terrible 99th percentile latency can feel randomly slow. That is the storage equivalent of a restaurant where most meals arrive quickly, except every tenth customer gets soup next Tuesday.

Method 4: monitor live disk activity with iostat

Benchmarks show what a disk can do under a test workload. Monitoring shows what the disk is doing right now. For that, use iostat, which is part of the sysstat package.

Run:

This updates every second and shows extended disk statistics. Useful columns include:

• r/s and w/s: Reads and writes per second.
• rkB/s and wkB/s: Read and write throughput.
• await: Average time for I/O requests to complete.
• %util: How busy the device is.

If %util is high and latency is rising, your disk may be a bottleneck. If throughput is low but latency is high, the workload may be random, fragmented, limited by queue depth, or waiting on another layer such as encryption, RAID, network storage, or a virtualized environment.

Method 5: test latency with ioping

Throughput is not everything. For interactive systems, latency is often the difference between “snappy” and “why did I click that three times?” The ioping tool measures disk latency in a style similar to network ping.

Install it:

Run a simple latency test in your target directory:

To test cached and direct behavior differently, check the tool’s available options on your distribution:

Low and consistent latency is usually better than one heroic throughput number. For databases and virtual machines, a disk with stable latency may outperform a flashier drive that produces occasional stalls.

Method 6: graphical Linux disk speed tests

Not every disk benchmark needs to look like it escaped from a server dungeon. Linux also has graphical tools.

GNOME Disks

GNOME Disks includes a built-in benchmark feature. Open Disks, choose the drive, open the menu, and select Benchmark Disk. It can test transfer rate and access time. Be careful with write benchmarks and read the warnings before starting.

KDiskMark

KDiskMark is a friendly graphical disk benchmark tool for Linux. It uses fio behind the scenes and presents results in a layout familiar to users who have seen CrystalDiskMark on Windows. It is helpful when you want readable results without building your own fio commands.

Testing disk speed on cloud servers

Cloud storage adds another layer of “it depends.” On AWS EBS, Google Persistent Disk, Oracle Cloud Block Volumes, Azure managed disks, and similar services, storage performance may depend on volume type, provisioned IOPS, provisioned throughput, disk size, instance type, burst limits, and network bandwidth.

For cloud Linux servers, fio is usually the preferred benchmark tool because it can generate enough parallel I/O to test the storage properly. A simple dd command may understate performance because it does not create the same queue depth or workload pressure.

When benchmarking cloud disks, test on non-production volumes where possible. Make sure the instance itself is capable of reaching the storage performance you expect. A tiny virtual machine may not be able to drive a very fast block volume, just as a bicycle cannot tow a freight train because you gave it motivational stickers.

Common mistakes when testing Linux disk speed

Using a test file that is too small

If the test file fits comfortably in RAM, your results may reflect cache speed rather than disk speed. Use larger files or direct I/O.

Testing while the system is busy

Package updates, backups, indexing, antivirus scans, containers, and databases can all distort benchmark results. Run tests on an idle system when possible.

Comparing different workloads

Do not compare a 1 MB sequential write test to a 4K random read test and declare one drive “faster.” They measure different things.

Ignoring latency

High throughput looks impressive, but latency affects real-world responsiveness. Always check latency for application servers, databases, and virtual machines.

Forgetting thermal throttling

NVMe drives can slow down when hot. If performance drops during longer tests, check drive temperature and airflow.

A practical Linux disk speed testing workflow

Here is a simple workflow you can use on most Linux machines:

1. Identify the disk and mount point with lsblk and df -h.
2. Check basic sequential write speed with dd.
3. Check sequential read speed with hdparm or fio.
4. Run fio random read, random write, and mixed tests.
5. Watch live behavior with iostat -xz 1.
6. Check latency with ioping.
7. Repeat tests and compare averages, percentiles, and consistency.

For a desktop user, this may be enough to compare an internal SSD, external USB drive, and network-mounted storage. For a server administrator, these tests can help diagnose slow databases, overloaded disks, weak cloud volume settings, or storage that performs well on paper but poorly under real workloads.

Example: interpreting real-world results

Imagine you run a sequential fio write test and get 1,800 MiB/s. That sounds excellent. Then you run a 4K random write test and see high latency with inconsistent 99th percentile results. What does that mean?

It means the drive is strong at large continuous writes but may struggle under small random write pressure. For copying large files, it will feel fast. For a database with many tiny updates, it may not feel nearly as impressive.

Now imagine another disk gives only 900 MiB/s sequential write speed but has much lower random write latency. That disk may feel better for virtual machines, development environments, or database work. The “best” disk is the one that matches your workload, not the one with the biggest number in a screenshot.

Extra experience: lessons learned from testing Linux disk speed

After testing disk speed on Linux systems for desktops, laptops, home servers, VPS instances, and cloud machines, one lesson becomes obvious: storage performance is rarely just about the disk. The disk is only one character in the story. The filesystem, kernel cache, I/O scheduler, encryption layer, USB bridge, SATA controller, NVMe temperature, virtual machine host, cloud volume type, and background services all walk onto the stage and start improvising.

One common surprise is the difference between external drives that look identical on the box. Two USB SSDs may both advertise fast transfer speeds, but one may sustain those speeds while the other falls sharply after its small cache fills. A five-second copy test may look great. A five-minute fio test may reveal the truth. Short tests are like first dates: pleasant, but not enough evidence to make long-term infrastructure decisions.

Another lesson is that random I/O matters more than many beginners expect. People often ask, “Why is my Linux system slow? My SSD says 3,000 MB/s.” The answer is usually that headline speed is sequential throughput. Booting apps, loading projects, running containers, compiling software, and updating packages involve many small files and metadata operations. That is where random reads, random writes, and latency become important.

On servers, I have found iostat especially useful because it shows what happens during real workloads. A benchmark may say the disk is healthy, but iostat -xz 1 during peak traffic may show high await times and heavy utilization. That tells a more practical story: users are not complaining about benchmark scores; they are complaining because the application stalls when the disk queue gets crowded.

Cloud testing brings its own comedy show. A user may buy a high-performance block volume and still get disappointing results because the virtual machine instance cannot deliver enough bandwidth. Another may run dd, see a low number, and assume the provider is terrible, when the real issue is that the test uses too little parallelism. With cloud storage, always check volume limits and instance limits together. Storage performance is a duet, not a solo act.

For laptops and workstations, temperature can be the hidden villain. NVMe drives are fast, but they can heat up quickly under sustained benchmarks. A drive may start at excellent speed, then slow down as thermal throttling begins. If your first run is fast and your third run is slower, check temperatures, airflow, and whether the SSD has a proper heatsink.

The best habit is to keep benchmark notes. Record the date, kernel version, filesystem, mount options, drive model, test command, file size, block size, queue depth, runtime, and whether the system was idle. Without notes, comparing benchmark results becomes a detective story where the detective lost the notebook and the suspect is “probably caching.”

Finally, do not chase perfect numbers. Disk benchmarks are tools, not trophies. A useful Linux disk speed test answers a practical question: “Is this storage fast enough for my workload?” If the system feels responsive, latency is stable, and real applications perform well, you do not need to spend the weekend arguing with a benchmark like it owes you money.

Conclusion

Testing disk speed in Linux is easy to start but takes a little care to do well. Use dd for quick write checks, hdparm for simple read tests, fio for serious benchmarking, iostat for live monitoring, and ioping for latency checks. For desktop users, GNOME Disks and KDiskMark provide convenient graphical options.

The most important rule is to match the test to the workload. Sequential speed matters for large files. Random I/O matters for databases and virtual machines. Latency matters for responsiveness. Cloud disks need enough queue depth and the right instance type. And no matter what tool you use, test safely, avoid production data, and remember that Linux cache can make a benchmark look more magical than it really is.

Note: This article is based on real Linux disk benchmarking practices and commonly used tools. Commands should be tested carefully in a safe directory, and important data should be backed up before running write benchmarks.