Fio was originally written to save me the hassle of writing special test case programs when I wanted to test a specific workload, either for performance reasons or to find/reproduce a bug. The process of writing such a test app can be tiresome, especially if you have to do it often. Hence I needed a tool that would be able to simulate a given I/O workload without resorting to writing a tailored test case again and again.
A test work load is difficult to define, though. There can be any number of processes or threads involved, and they can each be using their own way of generating I/O. You could have someone dirtying large amounts of memory in an memory mapped file, or maybe several threads issuing reads using asynchronous I/O. fio needed to be flexible enough to simulate both of these cases, and many more.
Fio spawns a number of threads or processes doing a particular type of I/O action as specified by the user. fio takes a number of global parameters, each inherited by the thread unless otherwise parameters given to them overriding that setting is given. The typical use of fio is to write a job file matching the I/O load one wants to simulate.
Running fio is normally the easiest part - you just give it the job file (or job files) as parameters:
fio [options] [jobfile] ...
and it will start doing what the jobfile tells it to do. You can give more than one job file on the command line, fio will serialize the running of those files. Internally that is the same as using the stonewall parameter described in the parameter section.
If the job file contains only one job, you may as well just give the parameters on the command line. The command line parameters are identical to the job parameters, with a few extra that control global parameters. For example, for the job file parameter
iodepth=2, the mirror command line option would be
--iodepth 2 or
--iodepth=2. You can also use the command line for giving more than one job entry. For each
--name option that fio sees, it will start a new job with that name. Command line entries following a
--name entry will apply to that job, until there are no more entries or a new
--name entry is seen. This is similar to the job file options, where each option applies to the current job until a new
 job entry is seen.
fio does not need to run as root, except if the files or devices specified in the job section requires that. Some other options may also be restricted, such as memory locking, I/O scheduler switching, and decreasing the nice value.
If jobfile is specified as
-, the job file will be read from standard input.
Interpreting the output
Some important metrics within the output.
Bandwidth statistics based on samples. Same names as the xlat stats, but also includes the number of samples taken (samples) and an approximate percentage of total aggregate bandwidth this thread received in its group (per). This last value is only really useful if the threads in this group are on the same disk, since they are then competing for disk access.
IOPS statistics based on samples. Same names as bw.
Test disk device
Create or edit
fio.conf.disk configuration file.
fio fio.conf.disk to test disk performance.
Test disk file
Create or edit
fio.conf.file configuration file.
fio fio.conf.file to test disk performace.
you need to specify size=
write-512k: you need to specify size=
size in the configuration file to fix that issue.