opendir=str Tell fio to recursively add any file it can find in this
directory and down the file system tree.
+lockfile=str Fio defaults to not doing any locking files before it does
+ IO to them. If a file or file descriptor is shared, fio
+ can serialize IO to that file to make the end result
+ consistent. This is usual for emulating real workloads that
+ share files. The lock modes are:
+
+ none No locking. The default.
+ exclusive Only one thread/process may do IO,
+ excluding all others.
+ readwrite Read-write locking on the file. Many
+ readers may access the file at the
+ same time, but writes get exclusive
+ access.
+
+ The option may be post-fixed with a lock batch number. If
+ set, then each thread/process may do that amount of IOs to
+ the file before giving up the lock. Since lock acqusition is
+ expensive, batching the lock/unlocks will speed up IO.
+
readwrite=str
rw=str Type of io pattern. Accepted values are:
zero_buffers If this option is given, fio will init the IO buffers to
all zeroes. The default is to fill them with random data.
+refill_buffers If this option is given, fio will refill the IO buffers
+ on every submit. The default is to only fill it at init
+ time and reuse that data. Only makes sense if zero_buffers
+ isn't specified, naturally. If data verification is enabled,
+ refill_buffers is also automatically enabled.
+
nrfiles=int Number of files to use for this job. Defaults to 1.
openfiles=int Number of files to keep open at the same time. Defaults to
posixaio glibc posix asynchronous io.
+ solarisaio Solaris native asynchronous io.
+
mmap File is memory mapped and data copied
to/from using memcpy(3).
cycles according to the cpuload= and
cpucycle= options. Setting cpuload=85
will cause that job to do nothing but burn
- 85% of the CPU.
+ 85% of the CPU. In case of SMP machines,
+ use numjobs=<no_of_cpu> to get desired CPU
+ usage, as the cpuload only loads a single
+ CPU at the desired rate.
guasi The GUASI IO engine is the Generic Userspace
Asyncronous Syscall Interface approach
not sync the file. The exception is the sg io engine, which
synchronizes the disk cache anyway.
-overwrite=bool If writing to a file, setup the file first and do overwrites.
+overwrite=bool If true, writes to a file will always overwrite existing
+ data. If the file doesn't already exist, it will be
+ created before the write phase begins. If the file exists
+ and is large enough for the specified write phase, nothing
+ will be done.
end_fsync=bool If true, fsync file contents when the job exits.
This differs from end_fsync in that it will happen on every
file close, not just at the end of the job.
-rwmixcycle=int Value in milliseconds describing how often to switch between
- reads and writes for a mixed workload. The default is
- 500 msecs.
-
rwmixread=int How large a percentage of the mix should be reads.
rwmixwrite=int How large a percentage of the mix should be writes. If both
fio doesn't track potential block rewrites which may alter
the calculated checksum for that block.
+softrandommap See norandommap. If fio runs with the random block map enabled
+ and it fails to allocate the map, if this option is set it
+ will continue without a random block map. As coverage will
+ not be as complete as with random maps, this option is
+ disabled by default.
+
nice=int Run the job with the given nice value. See man nice(2).
prio=int Set the io priority value of this job. Linux limits us to
bw (KiB/s) : min= 0, max= 1196, per=51.00%, avg=664.02, stdev=681.68
cpu : usr=1.49%, sys=0.25%, ctx=7969, majf=0, minf=17
IO depths : 1=0.1%, 2=0.3%, 4=0.5%, 8=99.0%, 16=0.0%, 32=0.0%, >32=0.0%
+ submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
+ complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/32768, short=0/0
lat (msec): 2=1.6%, 4=0.0%, 10=3.2%, 20=12.8%, 50=38.4%, 100=24.8%,
lat (msec): 250=15.2%, 500=0.0%, 750=0.0%, 1000=0.0%, >=2048=0.0%
16= entries includes depths up to that value but higher
than the previous entry. In other words, it covers the
range from 16 to 31.
+IO submit= How many pieces of IO were submitting in a single submit
+ call. Each entry denotes that amount and below, until
+ the previous entry - eg, 8=100% mean that we submitted
+ anywhere in between 5-8 ios per submit call.
+IO complete= Like the above submit number, but for completions instead.
IO issued= The number of read/write requests issued, and how many
of them were short.
IO latencies= The distribution of IO completion latencies. This is the