a string. The following types are used:
str String. This is a sequence of alpha characters.
-int Integer. A whole number value, can be negative.
+int Integer. A whole number value, can be negative. If prefixed with
+ 0x, the integer is assumed to be of base 16 (hexidecimal).
siint SI integer. A whole number value, which may contain a postfix
describing the base of the number. Accepted postfixes are k/m/g,
meaning kilo, mega, and giga. So if you want to specify 4096,
or receive, if the latter only the port
argument is used.
+ netsplice Like net, but uses splice/vmsplice to
+ map data and send/receive.
+
cpu Doesn't transfer any data, but burns CPU
cycles according to the cpuload= and
cpucycle= options. Setting cpuload=85
sched_setaffinity(2). This may not work on all supported
operating systems or kernel versions.
+cpus_allowed=str Controls the same options as cpumask, but it allows a text
+ setting of the permitted CPUs instead. So to use CPUs 1 and
+ 5, you would specify cpus_allowed=1,5.
+
startdelay=int Start this job the specified number of seconds after fio
has started. Only useful if the job file contains several
jobs, and you want to delay starting some jobs to a certain
to repeat the same workload a given number of times. Defaults
to 1.
+do_verify=bool Run the verify phase after a write phase. Only makes sense if
+ verify is set. Defaults to 1.
+
verify=str If writing to a file, fio can verify the file contents
after each iteration of the job. The allowed values are:
md5 Use an md5 sum of the data area and store
it in the header of each block.
+ crc64 Use an experimental crc64 sum of the data
+ area and store it in the header of each
+ block.
+
crc32 Use a crc32 sum of the data area and store
it in the header of each block.
+ crc16 Use a crc16 sum of the data area and store
+ it in the header of each block.
+
+ crc7 Use a crc7 sum of the data area and store
+ it in the header of each block.
+
+ sha512 Use sha512 as the checksum function.
+
+ sha256 Use sha256 as the checksum function.
+
+ meta Write extra information about each io
+ (timestamp, block number etc.). The block
+ number is verified.
+
+ pattern Fill the IO buffers with a specific pattern,
+ that we can use to verify. Depending on the
+ width of the pattern, fio will fill 1/2/3/4
+ bytes of the buffer at the time. The pattern
+ cannot be larger than a 32-bit quantity. The
+ given pattern is given as a postfix to this
+ option, ala: verify=pattern:0x5a. It accepts
+ both hex and dec values.
+
null Only pretend to verify. Useful for testing
internals with ioengine=null, not for much
else.
can ignore this option unless doing huge amounts of really
fast IO where the red-black tree sorting CPU time becomes
significant.
+
+verify_offset=siint Swap the verification header with data somewhere else
+ in the block before writing. Its swapped back before
+ verifying.
+
+verify_interval=siint Write the verification header at a finer granularity
+ than the blocksize. It will be written for chunks the
+ size of header_interval. blocksize should divide this
+ evenly.
+
+verify_fatal=bool Normally fio will keep checking the entire contents
+ before quitting on a block verification failure. If this
+ option is set, fio will exit the job on the first observed
+ failure.
stonewall Wait for preceeding jobs in the job file to exit, before
starting this one. Can be used to insert serialization
_ Thread reaped.
The other values are fairly self explanatory - number of threads
-currently running and doing io, rate of io since last check, and the estimated
-completion percentage and time for the running group. It's impossible to
-estimate runtime of the following groups (if any).
+currently running and doing io, rate of io since last check (read speed
+listed first, then write speed), and the estimated completion percentage
+and time for the running group. It's impossible to estimate runtime of
+the following groups (if any).
When fio is done (or interrupted by ctrl-c), it will show the data for
each thread, group of threads, and disks in that order. For each data
slat= Submission latency (avg being the average, stdev being the
standard deviation). This is the time it took to submit
the io. For sync io, the slat is really the completion
- latency, since queue/complete is one operation there.
+ latency, since queue/complete is one operation there. This
+ value can be in miliseconds or microseconds, fio will choose
+ the most appropriate base and print that. In the example
+ above, miliseconds is the best scale.
clat= Completion latency. Same names as slat, this denotes the
time from submission to completion of the io pieces. For
sync io, clat will usually be equal (or very close) to 0,
projects / fio.git / blobdiff