.. option:: --readonly
- Turn on safety read-only checks, preventing writes. The ``--readonly``
- option is an extra safety guard to prevent users from accidentally starting
- a write workload when that is not desired. Fio will only write if
- `rw=write/randwrite/rw/randrw` is given. This extra safety net can be used
- as an extra precaution as ``--readonly`` will also enable a write check in
- the I/O engine core to prevent writes due to unknown user space bug(s).
+ Turn on safety read-only checks, preventing writes and trims. The
+ ``--readonly`` option is an extra safety guard to prevent users from
+ accidentally starting a write or trim workload when that is not desired.
+ Fio will only modify the device under test if
+ `rw=write/randwrite/rw/randrw/trim/randtrim/trimwrite` is given. This
+ safety net can be used as an extra precaution.
.. option:: --eta=when
Specifies when real-time ETA estimate should be printed. `when` may be
- `always`, `never` or `auto`.
+ `always`, `never` or `auto`. `auto` is the default, it prints ETA
+ when requested if the output is a TTY. `always` disregards the output
+ type, and prints ETA when requested. `never` never prints ETA.
+
+.. option:: --eta-interval=time
+
+ By default, fio requests client ETA status roughly every second. With
+ this option, the interval is configurable. Fio imposes a minimum
+ allowed time to avoid flooding the console, less than 250 msec is
+ not supported.
.. option:: --eta-newline=time
Set the maximum number of threads/processes to support to `nr`.
NOTE: On Linux, it may be necessary to increase the shared-memory
- limit ('/proc/sys/kernel/shmmax') if fio runs into errors while
+ limit (:file:`/proc/sys/kernel/shmmax`) if fio runs into errors while
creating jobs.
.. option:: --server=args
.. option:: --client=hostname
Instead of running the jobs locally, send and run them on the given `hostname`
- or set of `hostname`s. See `Client/Server`_ section.
+ or set of `hostname`\s. See `Client/Server`_ section.
.. option:: --remote-config=file
Tell fio to terminate processing after the specified period of time. It
can be quite hard to determine for how long a specified job will run, so
this parameter is handy to cap the total runtime to a given time. When
- the unit is omitted, the value is intepreted in seconds.
+ the unit is omitted, the value is interpreted in seconds.
.. option:: time_based
named :file:`testfiles.4`. The default of :file:`$jobname.$jobnum.$filenum`
will be used if no other format specifier is given.
+ If you specify a path then the directories will be created up to the
+ main directory for the file. So for example if you specify
+ ``filename_format=a/b/c/$jobnum`` then the directories a/b/c will be
+ created before the file setup part of the job. If you specify
+ :option:`directory` then the path will be relative that directory,
+ otherwise it is treated as the absolute path.
+
.. option:: unique_filename=bool
To avoid collisions between networked clients, fio defaults to prefixing any
.. option:: fadvise_hint=str
- Use :manpage:`posix_fadvise(2)` to advise the kernel on what I/O patterns
- are likely to be issued. Accepted values are:
+ Use :manpage:`posix_fadvise(2)` or :manpage:`posix_fadvise(2)` to
+ advise the kernel on what I/O patterns are likely to be issued.
+ Accepted values are:
**0**
Backwards-compatible hint for "no hint".
.. option:: offset=int
Start I/O at the provided offset in the file, given as either a fixed size in
- bytes or a percentage. If a percentage is given, the next ``blockalign``-ed
- offset will be used. Data before the given offset will not be touched. This
+ bytes or a percentage. If a percentage is given, the generated offset will be
+ aligned to the minimum ``blocksize`` or to the value of ``offset_align`` if
+ provided. Data before the given offset will not be touched. This
effectively caps the file size at `real_size - offset`. Can be combined with
:option:`size` to constrain the start and end range of the I/O workload.
A percentage can be specified by a number between 1 and 100 followed by '%',
for example, ``offset=20%`` to specify 20%.
+.. option:: offset_align=int
+
+ If set to non-zero value, the byte offset generated by a percentage ``offset``
+ is aligned upwards to this value. Defaults to 0 meaning that a percentage
+ offset is aligned to the minimum block size.
+
.. option:: offset_increment=int
If this is provided, then the real offset becomes `offset + offset_increment
**zoned**
Zoned random distribution
+ **zoned_abs**
+ Zone absolute random distribution
+
When using a **zipf** or **pareto** distribution, an input value is also
needed to define the access pattern. For **zipf**, this is the `Zipf
theta`. For **pareto**, it's the `Pareto power`. Fio includes a test
random_distribution=zoned:60/10:30/20:8/30:2/40
- similarly to how :option:`bssplit` works for setting ranges and percentages
- of block sizes. Like :option:`bssplit`, it's possible to specify separate
- zones for reads, writes, and trims. If just one set is given, it'll apply to
- all of them.
+ A **zoned_abs** distribution works exactly like the **zoned**, except
+ that it takes absolute sizes. For example, let's say you wanted to
+ define access according to the following criteria:
+
+ * 60% of accesses should be to the first 20G
+ * 30% of accesses should be to the next 100G
+ * 10% of accesses should be to the next 500G
+
+ we can define an absolute zoning distribution with:
+
+ random_distribution=zoned_abs=60/20G:30/100G:10/500g
+
+ For both **zoned** and **zoned_abs**, fio supports defining up to
+ 256 separate zones.
+
+ Similarly to how :option:`bssplit` works for setting ranges and
+ percentages of block sizes. Like :option:`bssplit`, it's possible to
+ specify separate zones for reads, writes, and trims. If just one set
+ is given, it'll apply to all of them. This goes for both **zoned**
+ **zoned_abs** distributions.
.. option:: percentage_random=int[,int][,int]
and that some blocks may be read/written more than once. If this option is
used with :option:`verify` and multiple blocksizes (via :option:`bsrange`),
only intact blocks are verified, i.e., partially-overwritten blocks are
- ignored.
+ ignored. With an async I/O engine and an I/O depth > 1, it is possible for
+ the same block to be overwritten, which can cause verification errors. Either
+ do not use norandommap in this case, or also use the lfsr random generator.
.. option:: softrandommap=bool
.. option:: bssplit=str[,str][,str]
- Sometimes you want even finer grained control of the block sizes issued, not
- just an even split between them. This option allows you to weight various
- block sizes, so that you are able to define a specific amount of block sizes
- issued. The format for this option is::
+ Sometimes you want even finer grained control of the block sizes
+ issued, not just an even split between them. This option allows you to
+ weight various block sizes, so that you are able to define a specific
+ amount of block sizes issued. The format for this option is::
bssplit=blocksize/percentage:blocksize/percentage
- for as many block sizes as needed. So if you want to define a workload that
- has 50% 64k blocks, 10% 4k blocks, and 40% 32k blocks, you would write::
+ for as many block sizes as needed. So if you want to define a workload
+ that has 50% 64k blocks, 10% 4k blocks, and 40% 32k blocks, you would
+ write::
bssplit=4k/10:64k/50:32k/40
- Ordering does not matter. If the percentage is left blank, fio will fill in
- the remaining values evenly. So a bssplit option like this one::
+ Ordering does not matter. If the percentage is left blank, fio will
+ fill in the remaining values evenly. So a bssplit option like this one::
bssplit=4k/50:1k/:32k/
- would have 50% 4k ios, and 25% 1k and 32k ios. The percentages always add up
- to 100, if bssplit is given a range that adds up to more, it will error out.
+ would have 50% 4k ios, and 25% 1k and 32k ios. The percentages always
+ add up to 100, if bssplit is given a range that adds up to more, it
+ will error out.
Comma-separated values may be specified for reads, writes, and trims as
described in :option:`blocksize`.
- If you want a workload that has 50% 2k reads and 50% 4k reads, while having
- 90% 4k writes and 10% 8k writes, you would specify::
+ If you want a workload that has 50% 2k reads and 50% 4k reads, while
+ having 90% 4k writes and 10% 8k writes, you would specify::
- bssplit=2k/50:4k/50,4k/90,8k/10
+ bssplit=2k/50:4k/50,4k/90:8k/10
+
+ Fio supports defining up to 64 different weights for each data
+ direction.
.. option:: blocksize_unaligned, bs_unaligned
.. option:: refill_buffers
If this option is given, fio will refill the I/O 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.
+ submit. Only makes sense if :option:`zero_buffers` isn't specified,
+ naturally. Defaults to being unset i.e., the buffer is only filled at
+ init time and the data in it is reused when possible but if any of
+ :option:`verify`, :option:`buffer_compress_percentage` or
+ :option:`dedupe_percentage` are enabled then `refill_buffers` is also
+ automatically enabled.
.. option:: scramble_buffers=bool
.. option:: buffer_compress_percentage=int
- If this is set, then fio will attempt to provide I/O buffer content (on
- WRITEs) that compresses to the specified level. Fio does this by providing a
- mix of random data and a fixed pattern. The fixed pattern is either zeros,
- or the pattern specified by :option:`buffer_pattern`. If the pattern option
- is used, it might skew the compression ratio slightly. Note that this is per
- block size unit, for file/disk wide compression level that matches this
- setting, you'll also want to set :option:`refill_buffers`.
+ If this is set, then fio will attempt to provide I/O buffer content
+ (on WRITEs) that compresses to the specified level. Fio does this by
+ providing a mix of random data followed by fixed pattern data. The
+ fixed pattern is either zeros, or the pattern specified by
+ :option:`buffer_pattern`. If the `buffer_pattern` option is used, it
+ might skew the compression ratio slightly. Setting
+ `buffer_compress_percentage` to a value other than 100 will also
+ enable :option:`refill_buffers` in order to reduce the likelihood that
+ adjacent blocks are so similar that they over compress when seen
+ together. See :option:`buffer_compress_chunk` for how to set a finer or
+ coarser granularity for the random/fixed data region. Defaults to unset
+ i.e., buffer data will not adhere to any compression level.
.. option:: buffer_compress_chunk=int
- See :option:`buffer_compress_percentage`. This setting allows fio to manage
- how big the ranges of random data and zeroed data is. Without this set, fio
- will provide :option:`buffer_compress_percentage` of blocksize random data,
- followed by the remaining zeroed. With this set to some chunk size smaller
- than the block size, fio can alternate random and zeroed data throughout the
- I/O buffer.
+ This setting allows fio to manage how big the random/fixed data region
+ is when using :option:`buffer_compress_percentage`. When
+ `buffer_compress_chunk` is set to some non-zero value smaller than the
+ block size, fio can repeat the random/fixed region throughout the I/O
+ buffer at the specified interval (which particularly useful when
+ bigger block sizes are used for a job). When set to 0, fio will use a
+ chunk size that matches the block size resulting in a single
+ random/fixed region within the I/O buffer. Defaults to 512. When the
+ unit is omitted, the value is interpreted in bytes.
.. option:: buffer_pattern=str
writing. These buffers will be naturally dedupable. The contents of the
buffers depend on what other buffer compression settings have been set. It's
possible to have the individual buffers either fully compressible, or not at
- all. This option only controls the distribution of unique buffers.
+ all -- this option only controls the distribution of unique buffers. Setting
+ this option will also enable :option:`refill_buffers` to prevent every buffer
+ being identical.
.. option:: invalidate=bool
:manpage:`read(2)` and :manpage:`write(2)` for asynchronous
I/O. Requires :option:`filename` option to specify either block or
character devices.
+ The sg engine includes engine specific options.
**null**
Doesn't transfer any data, just pretends to. This is mainly used to
Doesn't transfer any data, but burns CPU cycles according to the
:option:`cpuload` and :option:`cpuchunks` options. Setting
:option:`cpuload`\=85 will cause that job to do nothing but burn 85%
- of the CPU. In case of SMP machines, use :option:`numjobs`=<nr_of_cpu>
+ of the CPU. In case of SMP machines, use :option:`numjobs`\=<nr_of_cpu>
to get desired CPU usage, as the cpuload only loads a
single CPU at the desired rate. A job never finishes unless there is
at least one non-cpuio job.
**guasi**
- The GUASI I/O engine is the Generic Userspace Asyncronous Syscall
+ The GUASI I/O engine is the Generic Userspace Asynchronous Syscall
Interface approach to async I/O. See
http://www.xmailserver.org/guasi-lib.html
**rdma**
The RDMA I/O engine supports both RDMA memory semantics
(RDMA_WRITE/RDMA_READ) and channel semantics (Send/Recv) for the
- InfiniBand, RoCE and iWARP protocols.
+ InfiniBand, RoCE and iWARP protocols. This engine defines engine
+ specific options.
**falloc**
I/O engine that does regular fallocate to simulate data transfer as
I/O engine that does regular EXT4_IOC_MOVE_EXT ioctls to simulate
defragment activity in request to DDIR_WRITE event.
+ **rados**
+ I/O engine supporting direct access to Ceph Reliable Autonomic
+ Distributed Object Store (RADOS) via librados. This ioengine
+ defines engine specific options.
+
**rbd**
I/O engine supporting direct access to Ceph Rados Block Devices
(RBD) via librbd without the need to use the kernel rbd driver. This
**pmemblk**
Read and write using filesystem DAX to a file on a filesystem
- mounted with DAX on a persistent memory device through the NVML
+ mounted with DAX on a persistent memory device through the PMDK
libpmemblk library.
**dev-dax**
Read and write using device DAX to a persistent memory device (e.g.,
- /dev/dax0.0) through the NVML libpmem library.
+ /dev/dax0.0) through the PMDK libpmem library.
**external**
Prefix to specify loading an external I/O engine object file. Append
details of writing an external I/O engine.
**filecreate**
- Simply create the files and do no IO to them. You still need to
+ Simply create the files and do no I/O to them. You still need to
set `filesize` so that all the accounting still occurs, but no
- actual IO will be done other than creating the file.
+ actual I/O will be done other than creating the file.
+
+ **libpmem**
+ Read and write using mmap I/O to a file on a filesystem
+ mounted with DAX on a persistent memory device through the PMDK
+ libpmem library.
I/O engine specific parameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
this will be the starting port number since fio will use a range of
ports.
-.. option:: hostname=str : [netsplice] [net]
+ [rdma]
+
+ The port to use for RDMA-CM communication. This should be the same value
+ on the client and the server side.
+
+.. option:: hostname=str : [netsplice] [net] [rdma]
- The hostname or IP address to use for TCP or UDP based I/O. If the job is
- a TCP listener or UDP reader, the hostname is not used and must be omitted
+ The hostname or IP address to use for TCP, UDP or RDMA-CM based I/O. If the job
+ is a TCP listener or UDP reader, the hostname is not used and must be omitted
unless it is a valid UDP multicast address.
.. option:: interface=str : [netsplice] [net]
Allocate space immediately inside defragment event, and free right
after event.
-.. option:: clustername=str : [rbd]
+.. option:: clustername=str : [rbd,rados]
Specifies the name of the Ceph cluster.
Specifies the name of the RBD.
-.. option:: pool=str : [rbd]
+.. option:: pool=str : [rbd,rados]
- Specifies the name of the Ceph pool containing RBD.
+ Specifies the name of the Ceph pool containing RBD or RADOS data.
-.. option:: clientname=str : [rbd]
+.. option:: clientname=str : [rbd,rados]
Specifies the username (without the 'client.' prefix) used to access the
Ceph cluster. If the *clustername* is specified, the *clientname* shall be
the full *type.id* string. If no type. prefix is given, fio will add
'client.' by default.
+.. option:: busy_poll=bool : [rbd,rados]
+
+ Poll store instead of waiting for completion. Usually this provides better
+ throughput at cost of higher(up to 100%) CPU utilization.
+
.. option:: skip_bad=bool : [mtd]
Skip operations against known bad blocks.
The size of the chunk to use for each file.
+.. option:: verb=str : [rdma]
+
+ The RDMA verb to use on this side of the RDMA ioengine connection. Valid
+ values are write, read, send and recv. These correspond to the equivalent
+ RDMA verbs (e.g. write = rdma_write etc.). Note that this only needs to be
+ specified on the client side of the connection. See the examples folder.
+
+.. option:: bindname=str : [rdma]
+
+ The name to use to bind the local RDMA-CM connection to a local RDMA device.
+ This could be a hostname or an IPv4 or IPv6 address. On the server side this
+ will be passed into the rdma_bind_addr() function and on the client site it
+ will be used in the rdma_resolve_add() function. This can be useful when
+ multiple paths exist between the client and the server or in certain loopback
+ configurations.
+
+.. option:: readfua=bool : [sg]
+
+ With readfua option set to 1, read operations include
+ the force unit access (fua) flag. Default is 0.
+
+.. option:: writefua=bool : [sg]
+
+ With writefua option set to 1, write operations include
+ the force unit access (fua) flag. Default is 0.
+
+.. option:: sg_write_mode=str : [sg]
+ Specify the type of write commands to issue. This option can take three values:
+
+ **write**
+ This is the default where write opcodes are issued as usual.
+ **verify**
+ Issue WRITE AND VERIFY commands. The BYTCHK bit is set to 0. This
+ directs the device to carry out a medium verification with no data
+ comparison. The writefua option is ignored with this selection.
+ **same**
+ Issue WRITE SAME commands. This transfers a single block to the device
+ and writes this same block of data to a contiguous sequence of LBAs
+ beginning at the specified offset. fio's block size parameter specifies
+ the amount of data written with each command. However, the amount of data
+ actually transferred to the device is equal to the device's block
+ (sector) size. For a device with 512 byte sectors, blocksize=8k will
+ write 16 sectors with each command. fio will still generate 8k of data
+ for each command but only the first 512 bytes will be used and
+ transferred to the device. The writefua option is ignored with this
+ selection.
I/O depth
~~~~~~~~~
changing data and the overlapping region has a non-zero size. Setting
``serialize_overlap`` tells fio to avoid provoking this behavior by explicitly
serializing in-flight I/Os that have a non-zero overlap. Note that setting
- this option can reduce both performance and the `:option:iodepth` achieved.
+ this option can reduce both performance and the :option:`iodepth` achieved.
Additionally this option does not work when :option:`io_submit_mode` is set to
offload. Default: false.
(https://en.wikipedia.org/wiki/Poisson_point_process). The lambda will be
10^6 / IOPS for the given workload.
+.. option:: rate_ignore_thinktime=bool
+
+ By default, fio will attempt to catch up to the specified rate setting,
+ if any kind of thinktime setting was used. If this option is set, then
+ fio will ignore the thinktime and continue doing IO at the specified
+ rate, instead of entering a catch-up mode after thinktime is done.
+
I/O latency
~~~~~~~~~~~
still respecting ordering. The result is the same I/O pattern to a given
device, but different timings.
+.. option:: replay_time_scale=int
+
+ When replaying I/O with :option:`read_iolog`, fio will honor the
+ original timing in the trace. With this option, it's possible to scale
+ the time. It's a percentage option, if set to 50 it means run at 50%
+ the original IO rate in the trace. If set to 200, run at twice the
+ original IO rate. Defaults to 100.
+
.. option:: replay_redirect=str
While replaying I/O patterns using :option:`read_iolog` the default behavior
Scale sector offsets down by this factor when replaying traces.
+.. option:: replay_skip=str
+
+ Sometimes it's useful to skip certain IO types in a replay trace.
+ This could be, for instance, eliminating the writes in the trace.
+ Or not replaying the trims/discards, if you are redirecting to
+ a device that doesn't support them. This option takes a comma
+ separated list of read, write, trim, sync.
+
Threads, processes and job synchronization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Set the I/O priority class. See man :manpage:`ionice(1)`.
-.. option:: cpumask=int
-
- Set the CPU affinity of this job. The parameter given is a bit mask of
- allowed CPUs the job may run on. So if you want the allowed CPUs to be 1
- and 5, you would pass the decimal value of (1 << 1 | 1 << 5), or 34. See man
- :manpage:`sched_setaffinity(2)`. This may not work on all supported
- operating systems or kernel versions. This option doesn't work well for a
- higher CPU count than what you can store in an integer mask, so it can only
- control cpus 1-32. For boxes with larger CPU counts, use
- :option:`cpus_allowed`.
-
.. option:: cpus_allowed=str
Controls the same options as :option:`cpumask`, but accepts a textual
- specification of the permitted CPUs instead. So to use CPUs 1 and 5 you
- would specify ``cpus_allowed=1,5``. This option also allows a range of CPUs
- to be specified -- say you wanted a binding to CPUs 1, 5, and 8 to 15, you
- would set ``cpus_allowed=1,5,8-15``.
+ specification of the permitted CPUs instead and CPUs are indexed from 0. So
+ to use CPUs 0 and 5 you would specify ``cpus_allowed=0,5``. This option also
+ allows a range of CPUs to be specified -- say you wanted a binding to CPUs
+ 0, 5, and 8 to 15, you would set ``cpus_allowed=0,5,8-15``.
+
+ On Windows, when ``cpus_allowed`` is unset only CPUs from fio's current
+ processor group will be used and affinity settings are inherited from the
+ system. An fio build configured to target Windows 7 makes options that set
+ CPUs processor group aware and values will set both the processor group
+ and a CPU from within that group. For example, on a system where processor
+ group 0 has 40 CPUs and processor group 1 has 32 CPUs, ``cpus_allowed``
+ values between 0 and 39 will bind CPUs from processor group 0 and
+ ``cpus_allowed`` values between 40 and 71 will bind CPUs from processor
+ group 1. When using ``cpus_allowed_policy=shared`` all CPUs specified by a
+ single ``cpus_allowed`` option must be from the same processor group. For
+ Windows fio builds not built for Windows 7, CPUs will only be selected from
+ (and be relative to) whatever processor group fio happens to be running in
+ and CPUs from other processor groups cannot be used.
.. option:: cpus_allowed_policy=str
enough CPUs are given for the jobs listed, then fio will roundrobin the CPUs
in the set.
+.. option:: cpumask=int
+
+ Set the CPU affinity of this job. The parameter given is a bit mask of
+ allowed CPUs the job may run on. So if you want the allowed CPUs to be 1
+ and 5, you would pass the decimal value of (1 << 1 | 1 << 5), or 34. See man
+ :manpage:`sched_setaffinity(2)`. This may not work on all supported
+ operating systems or kernel versions. This option doesn't work well for a
+ higher CPU count than what you can store in an integer mask, so it can only
+ control cpus 1-32. For boxes with larger CPU counts, use
+ :option:`cpus_allowed`.
+
.. option:: numa_cpu_nodes=str
Set this job running on specified NUMA nodes' CPUs. The arguments allow
<mode>[:<nodelist>]
- ``mode`` is one of the following memory poicies: ``default``, ``prefer``,
+ ``mode`` is one of the following memory policies: ``default``, ``prefer``,
``bind``, ``interleave`` or ``local``. For ``default`` and ``local`` memory
policies, no node needs to be specified. For ``prefer``, only one node is
allowed. For ``bind`` and ``interleave`` the ``nodelist`` may be as
each block. This will automatically use hardware acceleration
(e.g. SSE4.2 on an x86 or CRC crypto extensions on ARM64) but will
fall back to software crc32c if none is found. Generally the
- fatest checksum fio supports when hardware accelerated.
+ fastest checksum fio supports when hardware accelerated.
**crc32c-intel**
Synonym for crc32c.
previously written file. If the data direction includes any form of write,
the verify will be of the newly written data.
-.. option:: verifysort=bool
-
- If true, fio will sort written verify blocks when it deems it faster to read
- them back in a sorted manner. This is often the case when overwriting an
- existing file, since the blocks are already laid out in the file system. You
- can ignore this option unless doing huge amounts of really fast I/O where
- the red-black tree sorting CPU time becomes significant. Default: true.
-
-.. option:: verifysort_nr=int
-
- Pre-load and sort verify blocks for a read workload.
+ To avoid false verification errors, do not use the norandommap option when
+ verifying data with async I/O engines and I/O depths > 1. Or use the
+ norandommap and the lfsr random generator together to avoid writing to the
+ same offset with muliple outstanding I/Os.
.. option:: verify_offset=int
.. option:: write_bw_log=str
If given, write a bandwidth log for this job. Can be used to store data of
- the bandwidth of the jobs in their lifetime. The included
- :command:`fio_generate_plots` script uses :command:`gnuplot` to turn these
- text files into nice graphs. See :option:`write_lat_log` for behavior of
- given filename. For this option, the postfix is :file:`_bw.x.log`, where `x`
- is the index of the job (`1..N`, where `N` is the number of jobs). If
- :option:`per_job_logs` is false, then the filename will not include the job
- index. See `Log File Formats`_.
+ the bandwidth of the jobs in their lifetime.
-.. option:: write_lat_log=str
+ If no str argument is given, the default filename of
+ :file:`jobname_type.x.log` is used. Even when the argument is given, fio
+ will still append the type of log. So if one specifies::
- Same as :option:`write_bw_log`, except that this option stores I/O
- submission, completion, and total latencies instead. If no filename is given
- with this option, the default filename of :file:`jobname_type.log` is
- used. Even if the filename is given, fio will still append the type of
- log. So if one specifies::
+ write_bw_log=foo
- write_lat_log=foo
+ The actual log name will be :file:`foo_bw.x.log` where `x` is the index
+ of the job (`1..N`, where `N` is the number of jobs). If
+ :option:`per_job_logs` is false, then the filename will not include the
+ `.x` job index.
- The actual log names will be :file:`foo_slat.x.log`, :file:`foo_clat.x.log`,
- and :file:`foo_lat.x.log`, where `x` is the index of the job (`1..N`, where `N`
- is the number of jobs). This helps :command:`fio_generate_plots` find the
- logs automatically. If :option:`per_job_logs` is false, then the filename
- will not include the job index. See `Log File Formats`_.
+ The included :command:`fio_generate_plots` script uses :command:`gnuplot` to turn these
+ text files into nice graphs. See `Log File Formats`_ for how data is
+ structured within the file.
+
+.. option:: write_lat_log=str
+
+ Same as :option:`write_bw_log`, except this option creates I/O
+ submission (e.g., :file:`name_slat.x.log`), completion (e.g.,
+ :file:`name_clat.x.log`), and total (e.g., :file:`name_lat.x.log`)
+ latency files instead. See :option:`write_bw_log` for details about
+ the filename format and `Log File Formats`_ for how data is structured
+ within the files.
.. option:: write_hist_log=str
- Same as :option:`write_lat_log`, but writes I/O completion latency
- histograms. If no filename is given with this option, the default filename
- of :file:`jobname_clat_hist.x.log` is used, where `x` is the index of the
- job (`1..N`, where `N` is the number of jobs). Even if the filename is given,
- fio will still append the type of log. If :option:`per_job_logs` is false,
- then the filename will not include the job index. See `Log File Formats`_.
+ Same as :option:`write_bw_log` but writes an I/O completion latency
+ histogram file (e.g., :file:`name_hist.x.log`) instead. Note that this
+ file will be empty unless :option:`log_hist_msec` has also been set.
+ See :option:`write_bw_log` for details about the filename format and
+ `Log File Formats`_ for how data is structured within the file.
.. option:: write_iops_log=str
- Same as :option:`write_bw_log`, but writes IOPS. If no filename is given
- with this option, the default filename of :file:`jobname_type.x.log` is
- used, where `x` is the index of the job (`1..N`, where `N` is the number of
- jobs). Even if the filename is given, fio will still append the type of
- log. If :option:`per_job_logs` is false, then the filename will not include
- the job index. See `Log File Formats`_.
+ Same as :option:`write_bw_log`, but writes an IOPS file (e.g.
+ :file:`name_iops.x.log`) instead. See :option:`write_bw_log` for
+ details about the filename format and `Log File Formats`_ for how data
+ is structured within the file.
.. option:: log_avg_msec=int
:option:`log_avg_msec` is inaccurate. Setting this option makes fio log
histogram entries over the specified period of time, reducing log sizes for
high IOPS devices while retaining percentile accuracy. See
- :option:`log_hist_coarseness` as well. Defaults to 0, meaning histogram
- logging is disabled.
+ :option:`log_hist_coarseness` and :option:`write_hist_log` as well.
+ Defaults to 0, meaning histogram logging is disabled.
.. option:: log_hist_coarseness=int
Integer ranging from 0 to 6, defining the coarseness of the resolution of
the histogram logs enabled with :option:`log_hist_msec`. For each increment
in coarseness, fio outputs half as many bins. Defaults to 0, for which
- histogram logs contain 1216 latency bins. See `Log File Formats`_.
+ histogram logs contain 1216 latency bins. See :option:`write_hist_log`
+ and `Log File Formats`_.
.. option:: log_max_value=bool
Define the set of CPUs that are allowed to handle online log compression for
the I/O jobs. This can provide better isolation between performance
- sensitive jobs, and background compression work.
+ sensitive jobs, and background compression work. See
+ :option:`cpus_allowed` for the format used.
.. option:: log_store_compressed=bool
.. option:: lat_percentiles=bool
- Enable the reporting of percentiles of IO latencies. This is similar
+ Enable the reporting of percentiles of I/O latencies. This is similar
to :option:`clat_percentiles`, except that this includes the
submission latency. This option is mutually exclusive with
:option:`clat_percentiles`.
.. option:: percentile_list=float_list
- Overwrite the default list of percentiles for completion latencies and the
- block error histogram. Each number is a floating number in the range
- (0,100], and the maximum length of the list is 20. Use ``:`` to separate the
- numbers, and list the numbers in ascending order. For example,
- ``--percentile_list=99.5:99.9`` will cause fio to report the values of
- completion latency below which 99.5% and 99.9% of the observed latencies
- fell, respectively.
+ Overwrite the default list of percentiles for completion latencies and
+ the block error histogram. Each number is a floating number in the
+ range (0,100], and the maximum length of the list is 20. Use ``:`` to
+ separate the numbers, and list the numbers in ascending order. For
+ example, ``--percentile_list=99.5:99.9`` will cause fio to report the
+ values of completion latency below which 99.5% and 99.9% of the observed
+ latencies fell, respectively.
+
+.. option:: significant_figures=int
+
+ If using :option:`--output-format` of `normal`, set the significant
+ figures to this value. Higher values will yield more precise IOPS and
+ throughput units, while lower values will round. Requires a minimum
+ value of 1 and a maximum value of 10. Defaults to 4.
Error handling
short or dropped.
**IO latency**
- These values are for `--latency-target` and related options. When
+ These values are for :option:`latency_target` and related options. When
these options are engaged, this section describes the I/O depth required
to meet the specified latency target.
projects / fio.git / blobdiff