Puyu Wang

Using ‘dd’ to benchmark SSD

Linux Benchmark SSD

Using dd might be the simplest way to benchmark an SSD on Unix-like systems. It is also very dangerous (obviously). I only recommend this method in TEST environments.

By Puyu Wang

Published on Friday 2024-07-26

Last Modified on Friday 2024-07-26

Using dd to Benchmark an SSD

Benchmarking an SSD can provide valuable insights into its performance. One of the simplest, albeit risky, methods to do this on Unix-like systems is by using the dd command. This approach should be reserved for test environments only due to the potential risks involved.

Benchmarking Methods

Below are several dd commands used to benchmark an SSD:

# Basic write test
dd if=/dev/zero of=test bs=1M count=1024

# Write test with sync after command execution
dd if=/dev/zero of=test bs=1M count=1024 ; sync

# Write test with synchronized I/O for each operation
dd if=/dev/zero of=test bs=1M count=1024 oflag=sync

# Write test using direct I/O
dd if=/dev/zero of=test bs=1M count=1024 oflag=direct

# Write test with final synchronization
dd if=/dev/zero of=test bs=1M count=1024 conv=fsync

What do those commands mean?

dd if=/dev/zero of=test bs=1M count=1024 would tell the system to write ZERO bytes to a file called test which is 1024MiB,bs=1M means to read and write up to 1M bytes each time and count=1024 means to write 1024 times.

dd is not set by default to “sync”, that means the recent disk change might be cached and not be completely written before dd exiting. Consequently, you would find that dd would exit pretty fast.This would affect the benchmark results.

The next command is actually two commands being executed one after another. Anyone know about how Linux shell works would know that adding “; sync” does not change how the first part works. That means dd would print the benchmark results without waiting for disk sync. This command is not a real-world case.

“oflag” is the option to define the way dd writes.

oflag=direct means to use direct I/O for data.

oflag=sync means to use synchronized I/O for data and metadata. This is supposed to be the slowest because the system would sync after writing each MB(due to bs=1M ), in our case, it would be 1024 times. This is slow but not the real-world case either.

conv=fsync only ask the system sync once after dd commit the whole data. It tells the system to physically write everything, including the metadata, before exiting. This is the closest one to the real-world environments. I would recommend using this one to test your disks.