mreschke/speedtest-hd.sh

## speedtest-hd.sh
#!/usr/bin/env bash

# Robust HD/SDD/NVMe performance CLI utility
# Utilizing FIO for sequential/random writes/writes
# Dependencies: fio (apt install fio)
# See: https://cloud.google.com/compute/docs/disks/benchmarking-pd-performance
# See: https://arstechnica.com/gadgets/2020/02/how-fast-are-your-disks-find-out-the-open-source-way-with-fio/
# mReschke 2024-01-18

# CLI Parameters
path="$1"
option="$2"

# Main application flow
function main {

    # Show usage if no params
    if [ ! "$path" ]; then
        usage
    fi

    # Understand . path
    if [ "$path" == '.' ]; then
        path=$(pwd)
    fi

    # Check if path exists
    if [ ! -e "$path" ]; then
        echo "Path $path does not exist"
        exit 1
    fi

    # Must type y or n THEN press enter (which I like better)
    echo "NOTICE: 1GB free space on '$path' is required to perform the benchmark."
    echo -n "Are you ready to start a robust IO benchmark against '$path' ?"; read answer
    if [ "$answer" != "${answer#[Yy]}" ]; then
        echo "Great! Starting benchmark now!";
    else
        echo "Ok, cancelled!"
        exit 0
    fi

    # Use dd of fio based on param or defaults
    if [ "$option" == "--dd" ]; then
        dd_speedtest
    elif [ "$option" == "--fio" ]; then
        fio_speedtest
    elif [ "$option" == "" ]; then
        # If fio is installed, use it, else use dd
        echo ""
        if ! command -v fio &> /dev/null; then
            dd_speedtest
        else
            fio_speedtest
        fi
    fi
}

function fio_write_single_random_4k {
    # Single 4k Random Writes

    # This is a single process doing random 4K writes. This is where the pain
    # really, really lives; it's basically the worst possible thing you can ask a
    # disk to do. Where this happens most frequently in real life: copying home
    # directories and dotfiles, manipulating email stuff, some database operations,
    # source code trees.

    # When I ran this test against the high-performance SSDs in my Ubuntu
    # workstation, they pushed 127MiB/sec. The server just beneath it in the rack
    # only managed 33MiB/sec on its "high-performance" 7200RPM rust disks... but
    # even then, the vast majority of that speed is because the data is being
    # written asynchronously, allowing the operating system to batch it up into
    # larger, more efficient write operations.

    # If we add the argument --fsync=1, forcing the operating system to perform
    # synchronous writes (calling fsync after each block of data is written) the
    # picture gets much more grim: 2.6MiB/sec on the high-performance SSDs but
    # only 184KiB/sec on the "high-performance" rust. The SSDs were about four
    # times faster than the rust when data was written asynchronously but a
    # whopping fourteen times faster when

    # --name= is a required argument, but it's basically human-friendly fluff—fio will create files based on that name to test with, inside the working directory you're currently in.
    # --ioengine=posixaio sets the mode fio interacts with the filesystem. POSIX is a standard Windows, Macs, Linux, and BSD all understand, so it's great for portability—although inside fio itself, Windows users need to invoke --ioengine=windowsaio, not --ioengine=posixaio, unfortunately. AIO stands for Asynchronous Input Output and means that we can queue up multiple operations to be completed in whatever order the OS decides to complete them. (In this particular example, later arguments effectively nullify this.)
    # --rw=randwrite means exactly what it looks like it means: we're going to do random write operations to our test files in the current working directory. Other options include seqread, seqwrite, randread, and randrw, all of which should hopefully be fairly self-explanatory.
    # --bs=4k blocksize 4K. These are very small individual operations. This is where the pain lives; it's hard on the disk, and it also means a ton of extra overhead in the SATA, USB, SAS, SMB, or whatever other command channel lies between us and the disks, since a separate operation has to be commanded for each 4K of data.
    # --size=1g our test file(s) will be 1GB in size apiece. (We're only creating one, see next argument.)
    # --numjobs=1 we're only creating a single file, and running a single process commanding operations within that file. If we wanted to simulate multiple parallel processes, we'd do, eg, --numjobs=16, which would create 16 separate test files of --size size, and 16 separate processes operating on them at the same time.
    # --iodepth=1 this is how deep we're willing to try to stack commands in the OS's queue. Since we set this to 1, this is effectively pretty much the same thing as the sync IO engine—we're only asking for a single operation at a time, and the OS has to acknowledge receipt of every operation we ask for before we can ask for another. (It does not have to satisfy the request itself before we ask it to do more operations, it just has to acknowledge that we actually asked for it.)
    # --runtime=15 --time_based Run and even if we complete sooner, just start over again and keep going until 60 seconds is up.
    # --end_fsync=1 After all operations have been queued, keep the timer going until the OS reports that the very last one of them has been successfully completed—ie, actually written to disk.
    echo ""
    echo "Single 4K Random Writes (size=1G, time=15sec, jobs=1, iodepth=1)"
    x=`sudo fio \
        --name=fio-write-random-4k \
        --directory=$path \
        --ioengine=posixaio \
        --rw=randwrite \
        --bs=4k \
        --size=1g \
        --numjobs=1 \
        --iodepth=1 \
        --time_based --runtime=15 \
        --end_fsync=1`
    echo "  - $x " | /usr/bin/grep -A1 'Run status group' | tail -n1

    # Cleanup my test files
    rm -rf $path/fio-write-random-4k*
}

function fio_write_parallel_random_64k {
    # Parallel 64k Random Writes

    # This time, we're creating 16 separate 64MB files (still totaling 1GB, when
    # all put together) and we're issuing 64KB blocksized random write operations.
    # We're doing it with sixteen separate processes running in parallel, and
    # we're queuing up to 16 simultaneous asynchronous ops before we pause and wait
    # for the OS to start acknowledging their receipt.

    # This is a pretty decent approximation of a significantly busy system. It's
    # not doing any one particularly nasty thing—like running a database engine or
    # copying tons of dotfiles from a user's home directory—but it is coping with
    # a bunch of applications doing moderately demanding stuff all at once.

    # This is also a pretty good, slightly pessimistic approximation of a busy,
    # multi-user system like a NAS, which needs to handle multiple 1MB operations
    # simultaneously for different users. If several people or processes are trying
    # to read or write big files (photos, movies, whatever) at once, the OS tries
    # to feed them all data simultaneously. This pretty quickly devolves down to a
    # pattern of multiple random small block access. So in addition to "busy desktop
    # with lots of apps," think "busy fileserver with several people actively using it."

    # You will see a lot more variation in speed as you watch this operation play
    # out on the console. For example, the 4K single process test we tried first
    # wrote a pretty consistent 11MiB/sec on my MacBook Air's internal drive—but
    # this 16-process job fluctuated between about 10MiB/sec and 300MiB/sec during
    # the run, finishing with an average of 126MiB/sec.

    # Most of the variation you're seeing here is due to the operating system and
    # SSD firmware sometimes being able to aggregate multiple writes. When it
    # manages to aggregate them helpfully, it can write them in a way that allows
    # parallel writes to all the individual physical media stripes inside the SSD.
    # Sometimes, it still ends up having to give up and write to only a single
    # physical media stripe at a time—or a garbage collection or other maintenance
    # operation at the SSD firmware level needs to run briefly in the background,
    # slowing things down.
    echo ""
    echo "Parallel 64K Random Writes (size=1G, time=15sec, jobs=16, iodepth=16)"
    x=`sudo fio \
        --name=fio-write-random-64k \
        --directory=$path \
        --ioengine=posixaio \
        --rw=randwrite \
        --bs=64k \
        --size=64m \
        --numjobs=16 \
        --iodepth=16 \
        --time_based --runtime=15 \
        --end_fsync=1`
    echo "  - $x " | /usr/bin/grep -A1 'Run status group' | tail -n1

    # Cleanup my test files
    rm -rf $path/fio-write-random-64k*
}

function fio_write_single_sequential_1m {
    # Single 1M Random Writes

    # This is pretty close to the best-case scenario for a real-world system
    # doing real-world things. No, it's not quite as fast as a single, truly
    # contiguous write... but the 1MiB blocksize is large enough that it's quite
    # close. Besides, if literally any other disk activity is requested simultaneously
    # with a contiguous write, the "contiguous" write devolves to this level of
    # performance pretty much instantly, so this is a much more realistic test of
    # the upper end of storage performance on a typical system.

    # You'll see some kooky fluctuations on SSDs when doing this test. This is largely
    # due to the SSD's firmware having better luck or worse luck at any given time,
    # when it's trying to queue operations so that it can write across all physical
    # media stripes cleanly at once. Rust disks will tend to provide a much more
    # consistent, though typically lower, throughput across the run.

    # You can also see SSD performance fall off a cliff here if you exhaust an
    # onboard write cache—TLC and QLC drives tend to have small write cache areas
    # made of much faster MLC or SLC media. Once those get exhausted, the disk has
    # to drop to writing directly to the much slower TLC/QLC media where the data
    # eventually lands. This is the major difference between, for example, Samsung
    # EVO and Pro SSDs—the EVOs have slow TLC media with a fast MLC cache, where
    # the Pros use the higher-performance, higher-longevity MLC media throughout
    # the entire SSD.

    # If you have any doubt at all about a TLC or QLC disk's ability to sustain
    # heavy writes, you may want to experimentally extend your time duration here.
    # If you watch the throughput live as the job progresses, you'll see the impact
    # immediately when you run out of cache—what had been a fairly steady,
    # several-hundred-MiB/sec throughput will suddenly plummet to half the speed
    # or less and get considerably less stable as well.

    # However, you might choose to take the opposite position—you might not
    # expect to do sustained heavy writes very frequently, in which case you
    # actually are more interested in the on-cache behavior. What's important
    # here is that you understand both what you want to test, and how to test
    # it accurately.

    echo ""
    echo "Single 1M Sequential Writes (size=1G, time=15sec, jobs=1, iodepth=1)"
    x=`sudo fio \
        --name=fio-write-random-1m \
        --directory=$path \
        --ioengine=posixaio \
        --rw=write \
        --bs=1m \
        --size=1g \
        --numjobs=1 \
        --iodepth=1 \
        --time_based --runtime=15 \
        --end_fsync=1`
    echo "  - $x " | /usr/bin/grep -A1 'Run status group' | tail -n1

    # Cleanup my test files
    rm -rf $path/fio-write-random-1m*
}

function fio_read_sequential_1m {
    # Sequential Parallel Reads

    echo ""
    echo "Sequential 4x 1M Reads"
    x=`sudo fio \
        --name=fio-read-sequential-1m \
        --directory=$path \
        --ioengine=posixaio \
        --bs=1M \
        --numjobs=4 \
        --size=256M \
        --time_based --runtime=30s \
        --ramp_time=2s \
        --direct=1 \
        --verify=0 \
        --iodepth=64 \
        --rw=read \
        --group_reporting=1 \
        --iodepth_batch_submit=64 \
        --iodepth_batch_complete_max=64`
    echo "  - $x " | /usr/bin/grep -A1 'Run status group' | tail -n1
    rm -rf $path/fio-read-sequential-1m*
}

function fio_read_random_4k {
    # Random 4k Reads

    echo ""
    echo "Random 4k Reads"
    x=`sudo fio \
        --name=fio-read-random-4k \
        --directory=$path \
        --ioengine=posixaio \
        --rw=randread \
        --bs=4k \
        --size=1g \
        --time_based --runtime=30s \
        --ramp_time=2s \
        --direct=1 \
        --verify=0 \
        --iodepth=256 \
        --rw=read \
        --group_reporting=1 \
        --iodepth_batch_submit=256 \
        --iodepth_batch_complete_max=256`
    echo "  - $x " | /usr/bin/grep -A1 'Run status group' | tail -n1
    rm -rf $path/fio-read-random-4k*
}

function fio_speedtest {
    # Write tests
    fio_write_single_random_4k
    fio_write_parallel_random_64k
    fio_write_single_sequential_1m

    # Read Tests
    fio_read_sequential_1m
    fio_read_random_4k
}

function dd_speedtest {
    # Basic HD speed test using DD
    # mReschke 2017-07-11

    file=$path/bigfile
    size=1024

    echo "Running dd based HD/SSD/NVMe Benchmarks"
    echo "---------------------------------------"

    printf "Cached write speed...\n"
    dd if=/dev/zero of=$file bs=1M count=$size

    printf "\nUncached write speed...\n"
    dd if=/dev/zero of=$file bs=1M count=$size conv=fdatasync,notrunc

    printf "\nUncached read speed...\n"
    echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null
    dd if=$file of=/dev/null bs=1M count=$size

    printf "\nCached read speed...\n"
    dd if=$file of=/dev/null bs=1M count=$size

    rm $file
    printf "\nDone\n"
}

# Show help and usage information
function usage {
    echo "Robust Flexible Input/Output HD Speedtest"
    echo "  If FIO is installed, we use FIO for more detailed performance analysis."
    echo "  If FIO is not installed, we use basic DD analysis."
    echo "  You should apt install fio (pacman -S fio) for detailed analysis."
    echo "mReschke 2024-01-18"
    echo ""
    echo "NOTICE, this creates a 1GB file on the desired destination disk."
    echo "Please ensure you have write access with 1GB free space on destination."
    echo ""
    echo "Usage:"
    echo "  This will use FIO if installed, else DD"
    echo "    ./speedtest-hd /mnt/somedisk"
    echo "    ./speedtest-hd ."
    echo ""
    echo "  This will force FIO"
    echo "    ./speedtest-hd /mnt/somedisk --fio"
    echo "    ./speedtest-hd . --fio"
    echo ""
    echo "  This will force DD"
    echo "    ./speedtest-hd /mnt/somedisk --dd"
    echo "    ./speedtest-hd . --dd"
    exit 0
}

# Go
main
	#!/usr/bin/env bash

	# Robust HD/SDD/NVMe performance CLI utility
	# Utilizing FIO for sequential/random writes/writes
	# Dependencies: fio (apt install fio)
	# See: https://cloud.google.com/compute/docs/disks/benchmarking-pd-performance
	# See: https://arstechnica.com/gadgets/2020/02/how-fast-are-your-disks-find-out-the-open-source-way-with-fio/
	# mReschke 2024-01-18

	# CLI Parameters
	path="$1"
	option="$2"

	# Main application flow
	function main {

	# Show usage if no params
	if [ ! "$path" ]; then
	usage
	fi

	# Understand . path
	if [ "$path" == '.' ]; then
	path=$(pwd)
	fi

	# Check if path exists
	if [ ! -e "$path" ]; then
	echo "Path $path does not exist"
	exit 1
	fi

	# Must type y or n THEN press enter (which I like better)
	echo "NOTICE: 1GB free space on '$path' is required to perform the benchmark."
	echo -n "Are you ready to start a robust IO benchmark against '$path' ?"; read answer
	if [ "$answer" != "${answer#[Yy]}" ]; then
	echo "Great! Starting benchmark now!";
	else
	echo "Ok, cancelled!"
	exit 0
	fi

	# Use dd of fio based on param or defaults
	if [ "$option" == "--dd" ]; then
	dd_speedtest
	elif [ "$option" == "--fio" ]; then
	fio_speedtest
	elif [ "$option" == "" ]; then
	# If fio is installed, use it, else use dd
	echo ""
	if ! command -v fio &> /dev/null; then
	dd_speedtest
	else
	fio_speedtest
	fi
	fi
	}

	function fio_write_single_random_4k {
	# Single 4k Random Writes

	# This is a single process doing random 4K writes. This is where the pain
	# really, really lives; it's basically the worst possible thing you can ask a
	# disk to do. Where this happens most frequently in real life: copying home
	# directories and dotfiles, manipulating email stuff, some database operations,
	# source code trees.

	# When I ran this test against the high-performance SSDs in my Ubuntu
	# workstation, they pushed 127MiB/sec. The server just beneath it in the rack
	# only managed 33MiB/sec on its "high-performance" 7200RPM rust disks... but
	# even then, the vast majority of that speed is because the data is being
	# written asynchronously, allowing the operating system to batch it up into
	# larger, more efficient write operations.

	# If we add the argument --fsync=1, forcing the operating system to perform
	# synchronous writes (calling fsync after each block of data is written) the
	# picture gets much more grim: 2.6MiB/sec on the high-performance SSDs but
	# only 184KiB/sec on the "high-performance" rust. The SSDs were about four
	# times faster than the rust when data was written asynchronously but a
	# whopping fourteen times faster when

	# --name= is a required argument, but it's basically human-friendly fluff—fio will create files based on that name to test with, inside the working directory you're currently in.
	# --ioengine=posixaio sets the mode fio interacts with the filesystem. POSIX is a standard Windows, Macs, Linux, and BSD all understand, so it's great for portability—although inside fio itself, Windows users need to invoke --ioengine=windowsaio, not --ioengine=posixaio, unfortunately. AIO stands for Asynchronous Input Output and means that we can queue up multiple operations to be completed in whatever order the OS decides to complete them. (In this particular example, later arguments effectively nullify this.)
	# --rw=randwrite means exactly what it looks like it means: we're going to do random write operations to our test files in the current working directory. Other options include seqread, seqwrite, randread, and randrw, all of which should hopefully be fairly self-explanatory.
	# --bs=4k blocksize 4K. These are very small individual operations. This is where the pain lives; it's hard on the disk, and it also means a ton of extra overhead in the SATA, USB, SAS, SMB, or whatever other command channel lies between us and the disks, since a separate operation has to be commanded for each 4K of data.
	# --size=1g our test file(s) will be 1GB in size apiece. (We're only creating one, see next argument.)
	# --numjobs=1 we're only creating a single file, and running a single process commanding operations within that file. If we wanted to simulate multiple parallel processes, we'd do, eg, --numjobs=16, which would create 16 separate test files of --size size, and 16 separate processes operating on them at the same time.
	# --iodepth=1 this is how deep we're willing to try to stack commands in the OS's queue. Since we set this to 1, this is effectively pretty much the same thing as the sync IO engine—we're only asking for a single operation at a time, and the OS has to acknowledge receipt of every operation we ask for before we can ask for another. (It does not have to satisfy the request itself before we ask it to do more operations, it just has to acknowledge that we actually asked for it.)
	# --runtime=15 --time_based Run and even if we complete sooner, just start over again and keep going until 60 seconds is up.
	# --end_fsync=1 After all operations have been queued, keep the timer going until the OS reports that the very last one of them has been successfully completed—ie, actually written to disk.
	echo ""
	echo "Single 4K Random Writes (size=1G, time=15sec, jobs=1, iodepth=1)"
	x=`sudo fio \
	--name=fio-write-random-4k \
	--directory=$path \
	--ioengine=posixaio \
	--rw=randwrite \
	--bs=4k \
	--size=1g \
	--numjobs=1 \
	--iodepth=1 \
	--time_based --runtime=15 \
	--end_fsync=1`
	echo " - $x " \| /usr/bin/grep -A1 'Run status group' \| tail -n1

	# Cleanup my test files
	rm -rf $path/fio-write-random-4k*
	}

	function fio_write_parallel_random_64k {
	# Parallel 64k Random Writes

	# This time, we're creating 16 separate 64MB files (still totaling 1GB, when
	# all put together) and we're issuing 64KB blocksized random write operations.
	# We're doing it with sixteen separate processes running in parallel, and
	# we're queuing up to 16 simultaneous asynchronous ops before we pause and wait
	# for the OS to start acknowledging their receipt.

	# This is a pretty decent approximation of a significantly busy system. It's
	# not doing any one particularly nasty thing—like running a database engine or
	# copying tons of dotfiles from a user's home directory—but it is coping with
	# a bunch of applications doing moderately demanding stuff all at once.

	# This is also a pretty good, slightly pessimistic approximation of a busy,
	# multi-user system like a NAS, which needs to handle multiple 1MB operations
	# simultaneously for different users. If several people or processes are trying
	# to read or write big files (photos, movies, whatever) at once, the OS tries
	# to feed them all data simultaneously. This pretty quickly devolves down to a
	# pattern of multiple random small block access. So in addition to "busy desktop
	# with lots of apps," think "busy fileserver with several people actively using it."

	# You will see a lot more variation in speed as you watch this operation play
	# out on the console. For example, the 4K single process test we tried first
	# wrote a pretty consistent 11MiB/sec on my MacBook Air's internal drive—but
	# this 16-process job fluctuated between about 10MiB/sec and 300MiB/sec during
	# the run, finishing with an average of 126MiB/sec.

	# Most of the variation you're seeing here is due to the operating system and
	# SSD firmware sometimes being able to aggregate multiple writes. When it
	# manages to aggregate them helpfully, it can write them in a way that allows
	# parallel writes to all the individual physical media stripes inside the SSD.
	# Sometimes, it still ends up having to give up and write to only a single
	# physical media stripe at a time—or a garbage collection or other maintenance
	# operation at the SSD firmware level needs to run briefly in the background,
	# slowing things down.
	echo ""
	echo "Parallel 64K Random Writes (size=1G, time=15sec, jobs=16, iodepth=16)"
	x=`sudo fio \
	--name=fio-write-random-64k \
	--directory=$path \
	--ioengine=posixaio \
	--rw=randwrite \
	--bs=64k \
	--size=64m \
	--numjobs=16 \
	--iodepth=16 \
	--time_based --runtime=15 \
	--end_fsync=1`
	echo " - $x " \| /usr/bin/grep -A1 'Run status group' \| tail -n1

	# Cleanup my test files
	rm -rf $path/fio-write-random-64k*
	}

	function fio_write_single_sequential_1m {
	# Single 1M Random Writes

	# This is pretty close to the best-case scenario for a real-world system
	# doing real-world things. No, it's not quite as fast as a single, truly
	# contiguous write... but the 1MiB blocksize is large enough that it's quite
	# close. Besides, if literally any other disk activity is requested simultaneously
	# with a contiguous write, the "contiguous" write devolves to this level of
	# performance pretty much instantly, so this is a much more realistic test of
	# the upper end of storage performance on a typical system.

	# You'll see some kooky fluctuations on SSDs when doing this test. This is largely
	# due to the SSD's firmware having better luck or worse luck at any given time,
	# when it's trying to queue operations so that it can write across all physical
	# media stripes cleanly at once. Rust disks will tend to provide a much more
	# consistent, though typically lower, throughput across the run.

	# You can also see SSD performance fall off a cliff here if you exhaust an
	# onboard write cache—TLC and QLC drives tend to have small write cache areas
	# made of much faster MLC or SLC media. Once those get exhausted, the disk has
	# to drop to writing directly to the much slower TLC/QLC media where the data
	# eventually lands. This is the major difference between, for example, Samsung
	# EVO and Pro SSDs—the EVOs have slow TLC media with a fast MLC cache, where
	# the Pros use the higher-performance, higher-longevity MLC media throughout
	# the entire SSD.

	# If you have any doubt at all about a TLC or QLC disk's ability to sustain
	# heavy writes, you may want to experimentally extend your time duration here.
	# If you watch the throughput live as the job progresses, you'll see the impact
	# immediately when you run out of cache—what had been a fairly steady,
	# several-hundred-MiB/sec throughput will suddenly plummet to half the speed
	# or less and get considerably less stable as well.

	# However, you might choose to take the opposite position—you might not
	# expect to do sustained heavy writes very frequently, in which case you
	# actually are more interested in the on-cache behavior. What's important
	# here is that you understand both what you want to test, and how to test
	# it accurately.

	echo ""
	echo "Single 1M Sequential Writes (size=1G, time=15sec, jobs=1, iodepth=1)"
	x=`sudo fio \
	--name=fio-write-random-1m \
	--directory=$path \
	--ioengine=posixaio \
	--rw=write \
	--bs=1m \
	--size=1g \
	--numjobs=1 \
	--iodepth=1 \
	--time_based --runtime=15 \
	--end_fsync=1`
	echo " - $x " \| /usr/bin/grep -A1 'Run status group' \| tail -n1

	# Cleanup my test files
	rm -rf $path/fio-write-random-1m*
	}

	function fio_read_sequential_1m {
	# Sequential Parallel Reads

	echo ""
	echo "Sequential 4x 1M Reads"
	x=`sudo fio \
	--name=fio-read-sequential-1m \
	--directory=$path \
	--ioengine=posixaio \
	--bs=1M \
	--numjobs=4 \
	--size=256M \
	--time_based --runtime=30s \
	--ramp_time=2s \
	--direct=1 \
	--verify=0 \
	--iodepth=64 \
	--rw=read \
	--group_reporting=1 \
	--iodepth_batch_submit=64 \
	--iodepth_batch_complete_max=64`
	echo " - $x " \| /usr/bin/grep -A1 'Run status group' \| tail -n1
	rm -rf $path/fio-read-sequential-1m*
	}

	function fio_read_random_4k {
	# Random 4k Reads

	echo ""
	echo "Random 4k Reads"
	x=`sudo fio \
	--name=fio-read-random-4k \
	--directory=$path \
	--ioengine=posixaio \
	--rw=randread \
	--bs=4k \
	--size=1g \
	--time_based --runtime=30s \
	--ramp_time=2s \
	--direct=1 \
	--verify=0 \
	--iodepth=256 \
	--rw=read \
	--group_reporting=1 \
	--iodepth_batch_submit=256 \
	--iodepth_batch_complete_max=256`
	echo " - $x " \| /usr/bin/grep -A1 'Run status group' \| tail -n1
	rm -rf $path/fio-read-random-4k*
	}

	function fio_speedtest {
	# Write tests
	fio_write_single_random_4k
	fio_write_parallel_random_64k
	fio_write_single_sequential_1m

	# Read Tests
	fio_read_sequential_1m
	fio_read_random_4k
	}

	function dd_speedtest {
	# Basic HD speed test using DD
	# mReschke 2017-07-11

	file=$path/bigfile
	size=1024

	echo "Running dd based HD/SSD/NVMe Benchmarks"
	echo "---------------------------------------"

	printf "Cached write speed...\n"
	dd if=/dev/zero of=$file bs=1M count=$size

	printf "\nUncached write speed...\n"
	dd if=/dev/zero of=$file bs=1M count=$size conv=fdatasync,notrunc

	printf "\nUncached read speed...\n"
	echo 3 \| sudo tee /proc/sys/vm/drop_caches > /dev/null
	dd if=$file of=/dev/null bs=1M count=$size

	printf "\nCached read speed...\n"
	dd if=$file of=/dev/null bs=1M count=$size

	rm $file
	printf "\nDone\n"
	}

	# Show help and usage information
	function usage {
	echo "Robust Flexible Input/Output HD Speedtest"
	echo " If FIO is installed, we use FIO for more detailed performance analysis."
	echo " If FIO is not installed, we use basic DD analysis."
	echo " You should apt install fio (pacman -S fio) for detailed analysis."
	echo "mReschke 2024-01-18"
	echo ""
	echo "NOTICE, this creates a 1GB file on the desired destination disk."
	echo "Please ensure you have write access with 1GB free space on destination."
	echo ""
	echo "Usage:"
	echo " This will use FIO if installed, else DD"
	echo " ./speedtest-hd /mnt/somedisk"
	echo " ./speedtest-hd ."
	echo ""
	echo " This will force FIO"
	echo " ./speedtest-hd /mnt/somedisk --fio"
	echo " ./speedtest-hd . --fio"
	echo ""
	echo " This will force DD"
	echo " ./speedtest-hd /mnt/somedisk --dd"
	echo " ./speedtest-hd . --dd"
	exit 0
	}

	# Go
	main