These can be used on the command line or in the job file, and will be
automatically substituted with the current system values when the job
-is run.
+is run. Simple math is also supported on these keywords, so you can
+perform actions like:
+
+size=8*$mb_memory
+
+and get that properly expanded to 8 times the size of memory in the
+machine.
5.0 Detailed list of parameters
randrepeat=bool For random IO workloads, seed the generator in a predictable
way so that results are repeatable across repetitions.
+fallocate=bool By default, fio will use fallocate() to advise the system
+ of the size of the file we are going to write. This can be
+ turned off with fallocate=0. May not be available on all
+ supported platforms.
+
fadvise_hint=bool By default, fio will use fadvise() to advise the kernel
on what IO patterns it is likely to issue. Sometimes you
want to test specific IO patterns without telling the
not sync the file. The exception is the sg io engine, which
synchronizes the disk cache anyway.
-fsyncdata=int Like fsync= but uses fdatasync() to only sync data and not
+fdatasync=int Like fsync= but uses fdatasync() to only sync data and not
metadata blocks.
+ In FreeBSD there is no fdatasync(), this falls back to
+ using fsync()
+
+sync_file_range=str:val Use sync_file_range() for every 'val' number of
+ write operations. Fio will track range of writes that
+ have happened since the last sync_file_range() call. 'str'
+ can currently be one or more of:
+
+ wait_before SYNC_FILE_RANGE_WAIT_BEFORE
+ write SYNC_FILE_RANGE_WRITE
+ wait_after SYNC_FILE_RANGE_WAIT_AFTER
+
+ So if you do sync_file_range=wait_before,write:8, fio would
+ use SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE for
+ every 8 writes. Also see the sync_file_range(2) man page.
+ This option is Linux specific.
overwrite=bool If true, writes to a file will always overwrite existing
data. If the file doesn't already exist, it will be
it in the header of each block.
crc32c-intel Use hardware assisted crc32c calcuation
- provided on SSE4.2 enabled processors.
+ provided on SSE4.2 enabled processors. Falls
+ back to regular software crc32c, if not
+ supported by the system.
crc32 Use a crc32 sum of the data area and store
it in the header of each block.
size of header_interval. blocksize should divide this
evenly.
-verify_pattern=int If set, fio will fill the io buffers with this
+verify_pattern=str If set, fio will fill the io buffers with this
pattern. Fio defaults to filling with totally random
bytes, but sometimes it's interesting to fill with a known
pattern for io verification purposes. Depending on the
width of the pattern, fio will fill 1/2/3/4 bytes of the
- buffer at the time. The verify_pattern cannot be larger than
- a 32-bit quantity.
+ buffer at the time(it can be either a decimal or a hex number).
+ The verify_pattern if larger than a 32-bit quantity has to
+ be a hex number that starts with either "0x" or "0X".
verify_fatal=bool Normally fio will keep checking the entire contents
before quitting on a block verification failure. If this
verify_async_cpus=str Tell fio to set the given CPU affinity on the
async IO verification threads. See cpus_allowed for the
format used.
+
+verify_backlog=int Fio will normally verify the written contents of a
+ job that utilizes verify once that job has completed. In
+ other words, everything is written then everything is read
+ back and verified. You may want to verify continually
+ instead for a variety of reasons. Fio stores the meta data
+ associated with an IO block in memory, so for large
+ verify workloads, quite a bit of memory would be used up
+ holding this meta data. If this option is enabled, fio
+ will verify the previously written blocks before continuing
+ to write new ones.
+
+verify_backlog_batch=int Control how many blocks fio will verify
+ if verify_backlog is set. If not set, will default to
+ the value of verify_backlog (meaning the entire queue
+ is read back and verified).
stonewall Wait for preceeding jobs in the job file to exit, before
starting this one. Can be used to insert serialization
to replay a workload captured by blktrace. See blktrace
for how to capture such logging data. For blktrace replay,
the file needs to be turned into a blkparse binary data
- file first (blktrace <device> -d file_for_fio.bin).
+ file first (blkparse <device> -o /dev/null -d file_for_fio.bin).
write_bw_log=str If given, write a bandwidth log of the jobs in this job
file. Can be used to store data of the bandwidth of the
for doing these time calls will be excluded from other
uses. Fio will manually clear it from the CPU mask of other
jobs.
+
continue_on_error=bool Normally fio will exit the job on the first observed
failure. If this option is set, fio will continue the job when
there is a 'non-fatal error' (EIO or EILSEQ) until the runtime
given in the stats is the first error that was hit during the
run.
+cgroup=str Add job to this control group. If it doesn't exist, it will
+ be created. The system must have a mounted cgroup blkio
+ mount point for this to work. If your system doesn't have it
+ mounted, you can do so with:
+
+ # mount -t cgroup -o blkio none /cgroup
+
+cgroup_weight=int Set the weight of the cgroup to this value. See
+ the documentation that comes with the kernel, allowed values
+ are in the range of 100..1000.
+
+cgroup_nodelete=bool Normally fio will delete the cgroups it has created after
+ the job completion. To override this behavior and to leave
+ cgroups around after the job completion, set cgroup_nodelete=1.
+ This can be useful if one wants to inspect various cgroup
+ files after job completion. Default: false
+
+uid=int Instead of running as the invoking user, set the user ID to
+ this value before the thread/process does any work.
+
+gid=int Set group ID, see uid.
6.0 Interpreting the output
---------------------------