Linux and Unix Test Disk I/O Performance With dd Command

How can I use dd command on a Linux to test I/O performance of my hard disk drive? How do I check the performance of a hard drive including the read and write speed on a Linux operating systems? How can I use the dd command under Linux I/O performance test?

You can use the following commands on a Linux or Unix-like systems for simple sequential I/O performance test:

ADVERTISEMENTS

  • dd command : It is used to monitor the writing performance of a disk device on a Linux and Unix-like system.
    Tutorial details
    Difficulty Intermediate (rss)
    Root privileges Yes
    Requirements dd
    Time 15m
  • hdparm command : It is used to get/set hard disk parameters including test the reading and caching performance of a disk device on a Linux based system.

In this tutorial you will learn how to use the dd command to test disk I/O performance .

Use dd command to monitor the reading and writing performance of a disk device:

  1. Open a shell prompt.
  2. Or login to a remote server via ssh.
  3. Use the dd command to measure server throughput (write speed) dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
  4. Use the dd command to measure server latency dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync

The dd command is useful to find out simple sequential I/O performance.

Understanding dd command options

In this example, I’m using RAID-10 (Adaptec 5405Z with SAS SSD) array running on a Ubuntu Linux 14.04 LTS server. The basic syntax is as follows to find out server throughput:

 dd if=/dev/input.file  of=/path/to/output.file  bs=block-size  count=number-of-blocks  oflag=dsync
 ## GNU dd syntax ##
 ##########################################################
 ##***[Adjust bs and count as per your needs and setup]**##
 ##########################################################
 dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
 dd if=/dev/zero of=/tmp/test2.img bs=64M count=1 oflag=dsync
 dd if=/dev/zero of=/tmp/test3.img bs=1M count=256 conv=fdatasync
 dd if=/dev/zero of=/tmp/test4.img bs=8k count=10k
 dd if=/dev/zero of=/tmp/test4.img bs=512 count=1000 oflag=dsync
 ## OR alternate syntax for GNU/dd ##
 dd if=/dev/zero of=/tmp/testALT.img bs=1G count=1 conv=fdatasync

Sample outputs:

Fig.01: Ubuntu Linux Server with RAID10 and testing server throughput with dd

Fig.01: Ubuntu Linux Server with RAID10 and testing server throughput with dd

Please note that one gigabyte was written for the test and 135 MB/s was server throughput for this test. Where,

  • if=/dev/zero (if=/dev/input.file) : The name of the input file you want dd the read from.
  • of=/tmp/test1.img (of=/path/to/output.file) : The name of the output file you want dd write the input.file to.
  • bs=1G (bs=block-size) : Set the size of the block you want dd to use. 1 gigabyte was written for the test. Please note that Linux will need 1GB of free space in RAM. If your test system does not have sufficient RAM available, use a smaller parameter for bs (such as 128MB or 64MB and so on).
  • count=1 (count=number-of-blocks): The number of blocks you want dd to read.
  • oflag=dsync (oflag=dsync) : Use synchronized I/O for data. Do not skip this option. This option get rid of caching and gives you good and accurate results
  • conv=fdatasyn: Again, this tells dd to require a complete “sync” once, right before it exits. This option is equivalent to oflag=dsync.

Finding server latency time

In this example, 512 bytes were written one thousand times to get RAID10 server latency time:

dd if=/dev/zero of=/tmp/test2.img bs=512 count=1000 oflag=dsync

Sample outputs:

1000+0 records in
1000+0 records out
512000 bytes (512 kB) copied, 0.60362 s, 848 kB/s

Please note that server throughput and latency time depends upon server/application load too. So I recommend that you run these tests on a newly rebooted server as well as peak time to get better idea about your workload. You can now compare these numbers with all your devices.

But why the server throughput and latency time are so low?

Low values does not mean you are using slow hardware. The value can be low because of the HARDWARE RAID10 controller’s cache.

Use hdparm command to see buffered and cached disk read speed

I suggest you run the following commands 2 or 3 times Perform timings of device reads for benchmark and comparison purposes:

### Buffered disk read test for /dev/sda ##
hdparm -t /dev/sda1
## OR ##
hdparm -t /dev/sda

To perform timings of cache reads for benchmark and comparison purposes again run the following command 2-3 times (note the -T option):

## Cache read benchmark for /dev/sda ###
hdparm -T /dev/sda1
## OR ##
hdparm -T /dev/sda

OR combine both tests:

hdparm -Tt /dev/sda

Sample outputs:

Fig.02: Linux hdparm command to test reading and caching disk performance

Fig.02: Linux hdparm command to test reading and caching disk performance

Again note that due to filesystems caching on file operations, you will always see high read rates.

Use dd command on Linux to test read speed

To get accurate read test data, first discard caches before testing by running the following commands:

flush
echo 3 | sudo tee /proc/sys/vm/drop_caches
time dd if=/path/to/bigfile of=/dev/null bs=8k

Linux Laptop example

Run the following command:

### Debian Laptop Throughput With Cache ##
dd if=/dev/zero of=/tmp/laptop.bin bs=1G count=1 oflag=direct
 
### Deactivate the cache ###
hdparm -W0 /dev/sda
 
### Debian Laptop Throughput Without Cache ##
dd if=/dev/zero of=/tmp/laptop.bin bs=1G count=1 oflag=direct

Apple OS X Unix (Macbook pro) example

GNU dd has many more options but OS X/BSD and Unix-like dd command need to run as follows to test real disk I/O and not memory add sync option as follows:

## Run command 2-3 times to get good results ###
time sh -c "dd if=/dev/zero of=/tmp/testfile bs=100k count=1k && sync"

Sample outputs:

1024+0 records in
1024+0 records out
104857600 bytes transferred in 0.165040 secs (635346520 bytes/sec)
 
real	0m0.241s
user	0m0.004s
sys	0m0.113s

So I’m getting 635346520 bytes (635.347 MB/s) write speed on my MBP.

Not a fan of the command line tools…?

You can use disk utility (gnome-disk-utility) on a Linux or Unix based system to get the same information. The following screenshot is taken from my Fedora Linux v22 VM and Ubuntu 20.04 desktop:

Graphical method

Click on the “Activities” or press the “Super” key to switch between the Activities overview and desktop. Type “Disks”

Fig.03: Start the Gnome disk utility

Fig.03: Start the Gnome disk utility

Select your hard disk at left pane and click on configure button and click on “Benchmark partition”:
Fig.04: Benchmark disk/partition

Fig.04: Benchmark disk/partition

Finally, click on the “Start Benchmark…” button (you may be promoted for the admin username and password):
Fig.05: Final benchmark result

Fig.05: Final benchmark result

Running Disks tool under Ubuntu 20.04 LTS:

  1. First, open Disks from the Activities overview.
  2. Next choose the disk from the list in the left pane.
  3. Select the menu button and select Benchmark disk… from the menu.
  4. Click Start Benchmark… and adjust the Transfer Rate and Access Time parameters as desired.
  5. Finally click Start Benchmarking to test how fast data can be read from the disk. Administrative privileges may be required. Enter your password, or the password for the requested system administrator account.
Linux and Unix Test Disk I/O Performance With dd Command

Test the performance of your hard disk using ‘Disks’

Which method and command do you recommend to use to test disk I/O performance?

  • I recommend dd command on all Unix-like systems (time sh -c "dd if=/dev/zero of=/tmp/testfile bs=100k count=1k && sync"
  • If you are using GNU/Linux use the dd command (dd if=/dev/zero of=/tmp/testALT.img bs=1G count=1 conv=fdatasync)
  • Make sure you adjust count and bs arguments as per your setup to get a good set of result.
  • The GUI method is recommended only for Linux/Unix laptop users running Gnome 2 or 3 desktop.
  • For detailed I/O performance benchmarking use the fio command
  • We use the IOzone. It is a filesystem benchmark tool. The benchmark generates and measures a variety of file operations.

Conclusion

You learned how to use the dd under Linux or Unix for testing simple and sequential I/O performance measurement. For detailed I/O performance benchmarking try the "The Flexible I/O Tester (FIO)" for Unix or Linux. See How To Linux Check IDE / SATA Hard Disk Transfer Speed and man pages: hdparm(1) for more information.

🐧 If you liked this page, please support my work on Patreon or with a donation.
🐧 Get the latest tutorials on SysAdmin, Linux/Unix, Open Source/DevOps topics:
CategoryList of Unix and Linux commands
File Managementcat
FirewallAlpine Awall CentOS 8 OpenSUSE RHEL 8 Ubuntu 16.04 Ubuntu 18.04 Ubuntu 20.04
Network Utilitiesdig host ip nmap
OpenVPNCentOS 7 CentOS 8 Debian 10 Debian 8/9 Ubuntu 18.04 Ubuntu 20.04
Package Managerapk apt
Processes Managementbg chroot cron disown fg jobs killall kill pidof pstree pwdx time
Searchinggrep whereis which
User Informationgroups id lastcomm last lid/libuser-lid logname members users whoami who w
WireGuard VPNAlpine CentOS 8 Debian 10 Firewall Ubuntu 20.04

ADVERTISEMENTS
14 comments… add one
  • kreso Aug 8, 2015 @ 20:14

    Hi,

    looking at that strange uneven graph I think that Virtualbox can be blamed maybe? ,, but the numbers are impresive nevertheless :) Thanks for great post

  • Jalal Hajigholamali Aug 9, 2015 @ 5:34

    Hi,
    Very useful article
    Thanks a lot

  • Jeff Darcy Aug 9, 2015 @ 10:35

    As a file system developer, I believe there should be a special place in hell for people who test storage performance using dd. At its very best, it tells you about one rarely-relevant kind of performance – sequential single-stream write bandwidth. It won’t reveal anything about performance with multiple threads or deeper queues, latency, variability, etc. “I tested with dd and it was {fast,slow}” is one of the least informative things to see in a benchmark or bug report. The usual starting point for storage-performance testing is iozone, which is just as portable as dd and in the same ballpark with respect to ease of use. Fio can do an even better job of simulating the way that storage is actually used under real workloads, but it’s considerably more complicated. With such tools readily available, using dd to measure performance is a bit like using a ruler to measure temperature.

    • -Sx- Aug 12, 2015 @ 2:58

      Agreed but dd is still a good place to start.

      -Sx-

    • Joe Jul 31, 2020 @ 12:33

      AGREEED!!! and that place will be full of “DD peoples” thinking why they are there!
      This type of dd checks are useless… if you do it, in 99% of cases you will see a wonderfull timings and you finish thinking why you still having poor performace in your app or service…
      DO NOT USE DD if you want REAL data of I/O or FILE benchmarks! USE FIO!

    • Richard Dylan Aug 26, 2020 @ 2:07

      Not if you’re shuffling around mainly large files, like multimedia, one at a time (like a file manager will for a mechanical HDD). I very much care for this use case and I’m almost sure that DD approximates this well with file sizes that are >2 GB.

  • Jeff Darnit Aug 12, 2015 @ 3:28

    JDarcy, you are an idiot. Seriously? Are you “that” upset?!!!

    • Unix Unicorn Aug 14, 2015 @ 4:16

      Darnit!

  • Ariel Aug 12, 2015 @ 10:25

    very interesting, thanks for sharing :-)

  • SK Aug 15, 2015 @ 2:18

    Hello, I have some trouble understanding this: GNU dd has many more options but OS X/BSD and Unix-like dd command need to run as follows to test real disk I/O and not memory add sync option as follows
    What does “memory add sync” mean? I’m a tyro in such field.Thanks.

  • Bryn Aug 17, 2015 @ 1:32

    Yeaaaah, forget dd, forget hdparm. Virtually every distro these days includes bonnie++ which works quite well and tests read/write/rewrite (important!) as well as random I/O, file delete and create plus seek times. Bonnie has been around forever, I don’t know why anyone would be using dd or hdparm.

    IOZone is great, as it runs on a variety of platforms, but it probably isn’t in your distro’s repository already.

  • Alakh May 13, 2017 @ 13:21

    Very nice write up! Thank you so much.

  • thiamael Sep 5, 2017 @ 11:51

    Nice work. i just have a question or two around oflag.
    – first, why using “dsync” over “direct”. I probably have misunderstood it but in the description, “direct” option is supposed to get rid of the buffer cache as dsync do not even talk about any cache. is the description misleading or am i mixing up buffer cache and cache?
    – I also saw the existence of iflag (for input file). Is using the oflag sufficient in writing and reading or is there a case where iflag can be useful ?

  • AnonDell Aug 26, 2020 @ 4:56

    What about IOzone http://www.iozone.org/ and Fio https://fio.readthedocs.io/en/latest/fio_doc.html. Both are made for this kind of work, isn’t it?

Leave a Reply

Your email address will not be published.

Use HTML <pre>...</pre>, <code>...</code> and <kbd>...</kbd> for code samples.