How to Test Disk Speed on Ubuntu and Linux: fio, dd, hdparm and SSD Health Checks

Updated: 10 October 2026 · Applies to: Ubuntu 24.04 (fio 3.36, hdparm 9.65, smartmontools 7.4, GNOME Disks 46); same packages on Debian 13 (fio 3.39) and AlmaLinux 10 (fio 3.36)

To test disk speed on Ubuntu or any Linux server, install fio and measure sequential and random reads and writes on a test file: fio --name=seqwrite --filename=fio.test --size=1G --rw=write --bs=1M --direct=1 --group_reporting. For a 10-second check use dd if=/dev/zero of=ddtest bs=1M count=1024 oflag=direct, and on Ubuntu Desktop open Disks and choose Benchmark Disk…. SSD health is a separate test: smartctl -H /dev/nvme0n1 (or /dev/sda).

Before you start

• Work in a folder on the disk you want to measure with at least 2 GB free, for example /root or /var/tmp. Avoid /tmp and /dev/shm: they are often in RAM.
• Tests load the disk heavily. On a busy production server, run them at a quiet time, and run each test three times.
• Never write to a device name such as /dev/sda: that overwrites the disk. Always write to a test file.

Method 1: fio (recommended)

1. Install fio: sudo apt install fio (Ubuntu, Debian) or sudo dnf install fio (AlmaLinux, Rocky Linux, RHEL).
2. Sequential write (large files, backups):

   fio --name=seqwrite --filename=fio.test --size=1G --rw=write --bs=1M --direct=1 --ioengine=libaio --group_reporting

3. Sequential read of the same file: run the same command with --name=seqread --rw=read.
4. Random 4K reads, which matter most for databases and busy websites:

   fio --name=randread --filename=fio.test --size=1G --rw=randread --bs=4k --iodepth=32 --direct=1 --ioengine=libaio --runtime=30 --time_based --group_reporting

5. Random writes: the same with --rw=randwrite.
6. Delete the test file: rm fio.test

The line to read is the one starting with write: or read:. This sample shows the format only. It came from a sequential write inside a test container on a busy lab machine, using the slower --ioengine=psync (see Common problems), so your numbers will be different:

seqwrite: (groupid=0, jobs=1): err= 0: pid=3179: Fri Oct  9 19:13:54 2026
  write: IOPS=84, BW=84.8MiB/s (88.9MB/s)(256MiB/3020msec); 0 zone resets
    clat (usec): min=3134, max=87643, avg=11763.33, stdev=21061.66
...
Run status group 0 (all jobs):
  WRITE: bw=84.8MiB/s (88.9MB/s), 84.8MiB/s-84.8MiB/s (88.9MB/s-88.9MB/s), io=256MiB (268MB), run=3020-3020msec

(output shortened) BW is the throughput, IOPS the operations per second and clat the time each request took (in microseconds here). For sequential tests look at BW; for random 4K tests look at IOPS and latency. --direct=1 bypasses the page cache, so you measure the disk and not the server's RAM.

As a rough guide: a hard disk manages about 100 to 250 MB/s sequential and a few hundred random IOPS. A SATA SSD tops out at roughly 500 to 550 MB/s because of the SATA link. NVMe drives reach several GB/s and far higher IOPS. Virtual servers often have per-server limits, so their numbers depend on the plan as much as on the drive.

Method 2: a quick check with dd

$ dd if=/dev/zero of=ddtest bs=1M count=256 oflag=direct
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 2.21886 s, 121 MB/s
$ dd if=ddtest of=/dev/null bs=1M iflag=direct
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 4.47273 s, 60.0 MB/s
$ rm ddtest

Use count=1024 (1 GiB) or more on a real test. oflag=direct and iflag=direct bypass the cache in both directions, so you do not need to clear the server's cache with drop_caches first. conv=fdatasync instead of oflag=direct measures a normal buffered write that is flushed to disk at the end.

dd measures only one sequential stream, and zeros compress very well, so storage with compression can report far higher speeds than real data gets. Use fio for decisions.

Method 3: raw read speed with hdparm

1. Install it: sudo apt install hdparm or sudo dnf install hdparm.
2. Find the disk name: lsblk -d -o NAME,SIZE,MODEL (for example sda, vda or nvme0n1).
3. Run sudo hdparm -tT /dev/sda. It only reads, so it is safe on a disk with data.

According to the hdparm manual, -t (Timing buffered disk reads) is the disk's sequential read speed, -T (Timing cached reads) measures the cache and memory rather than the disk, and both should be repeated two or three times on an otherwise idle system. Adding --direct reads past the page cache.

Method 4: Ubuntu Desktop (Disks)

According to the Ubuntu desktop help (GNOME Disks):

1. Open Disks from the Activities overview and choose the disk in the left pane.
2. Click the menu button and select Benchmark Disk….
3. Click Start Benchmark…, adjust Transfer Rate and Access Time if you want, and click Start Benchmarking…. Tick Perform write-benchmark to test writes too.

The minimum, maximum and average read and write rates and the average access time appear below the graph.

SSD test on Linux: health and wear

Speed is only half the picture for an SSD. Install smartmontools and check the drive's own health report:

sudo smartctl -H /dev/nvme0n1     # overall result: PASSED or FAILED!
sudo smartctl -a /dev/nvme0n1     # all values

On NVMe drives, watch Percentage Used (an estimate of wear: 100% means the rated endurance is used up), Available Spare and Media and Data Integrity Errors. SATA SSD attribute names differ by vendor. sudo nvme smart-log /dev/nvme0 (package nvme-cli) shows the same NVMe data. On a VPS the disk is virtual, so SMART data is usually not available; the host's drives are monitored by the provider. More in how to use smartctl and check whether a disk is SSD or HDD.

SSDs also need TRIM to stay fast. On Ubuntu 24.04, fstrim.timer is enabled out of the box and trims mounted file systems weekly; sudo fstrim -av runs it by hand.

Ubuntu chkdsk: check the disk for errors

Ubuntu has no chkdsk. The equivalents are:

• File system errors: sudo fsck -f /dev/sdb1 on an unmounted partition. For the root file system, add fsck.mode=force to the kernel command line for one boot (press e in the GRUB menu); according to the systemd-fsck manual this forces a full check. On the desktop, Disks has Check Filesystem… and Repair Filesystem… in the menu under Volumes. Full guide: how to use fsck to repair file system errors.
• Bad sectors: smartctl as above, or badblocks: see check a disk for bad blocks and errors. In Disks: SMART Data & Self-Tests…, where the Overall Assessment should say "Disk is OK".

Common problems

• "destination does not support O_DIRECT" or "Invalid argument": we got this when the test file was on /dev/shm (RAM). Move to a folder on the real disk.
• libaio or io_uring errors: inside a container on our AlmaLinux 9 test host, libaio failed with func=get_events, error=Unknown error -1 and io_uring with your kernel doesn't support io_uring. --ioengine=psync (fio's default on Linux) worked; for random tests add --numjobs=4 to keep several requests in flight.
• Results vary between runs on a VPS: VPS storage is shared and often has an IOPS limit per server. Run the test several times and compare averages.

If a Ucartz server shows results far below what you expect, open a support ticket and include the full fio output.

Official documentation: fio documentation.