for both direct and buffered IO.
This engine defines engine specific options.
+ **io_uring_cmd**
+ Fast Linux native asynchronous I/O for pass through commands.
+ This engine defines engine specific options.
+
**libaio**
Linux native asynchronous I/O. Note that Linux may only support
queued behavior with non-buffered I/O (set ``direct=1`` or
values for trim IOs are ignored. This option is mutually exclusive with
the :option:`cmdprio_percentage` option.
-.. option:: fixedbufs : [io_uring]
+.. option:: fixedbufs : [io_uring] [io_uring_cmd]
+
+ If fio is asked to do direct IO, then Linux will map pages for each
+ IO call, and release them when IO is done. If this option is set, the
+ pages are pre-mapped before IO is started. This eliminates the need to
+ map and release for each IO. This is more efficient, and reduces the
+ IO latency as well.
+
+.. option:: nonvectored : [io_uring] [io_uring_cmd]
+
+ With this option, fio will use non-vectored read/write commands, where
+ address must contain the address directly. Default is -1.
- If fio is asked to do direct IO, then Linux will map pages for each
- IO call, and release them when IO is done. If this option is set, the
- pages are pre-mapped before IO is started. This eliminates the need to
- map and release for each IO. This is more efficient, and reduces the
- IO latency as well.
+.. option:: force_async=int : [io_uring] [io_uring_cmd]
-.. option:: registerfiles : [io_uring]
+ Normal operation for io_uring is to try and issue an sqe as
+ non-blocking first, and if that fails, execute it in an async manner.
+ With this option set to N, then every N request fio will ask sqe to
+ be issued in an async manner. Default is 0.
+
+.. option:: registerfiles : [io_uring] [io_uring_cmd]
With this option, fio registers the set of files being used with the
kernel. This avoids the overhead of managing file counts in the kernel,
making the submission and completion part more lightweight. Required
for the below :option:`sqthread_poll` option.
-.. option:: sqthread_poll : [io_uring] [xnvme]
+.. option:: sqthread_poll : [io_uring] [io_uring_cmd] [xnvme]
Normally fio will submit IO by issuing a system call to notify the
kernel of available items in the SQ ring. If this option is set, the
This frees up cycles for fio, at the cost of using more CPU in the
system.
-.. option:: sqthread_poll_cpu : [io_uring]
+.. option:: sqthread_poll_cpu : [io_uring] [io_uring_cmd]
When :option:`sqthread_poll` is set, this option provides a way to
define which CPU should be used for the polling thread.
+.. option:: cmd_type=str : [io_uring_cmd]
+
+ Specifies the type of uring passthrough command to be used. Supported
+ value is nvme. Default is nvme.
+
.. option:: hipri
- [io_uring], [xnvme]
+ [io_uring] [io_uring_cmd] [xnvme]
If this option is set, fio will attempt to use polled IO completions.
Normal IO completions generate interrupts to signal the completion of
the full *type.id* string. If no type. prefix is given, fio will add
'client.' by default.
+.. option:: conf=str : [rados]
+
+ Specifies the configuration path of ceph cluster, so conf file does not
+ have to be /etc/ceph/ceph.conf.
+
.. option:: busy_poll=bool : [rbd,rados]
Poll store instead of waiting for completion. Usually this provides better
Write the issued I/O patterns to the specified file. See
:option:`read_iolog`. Specify a separate file for each job, otherwise the
- iologs will be interspersed and the file may be corrupt.
+ iologs will be interspersed and the file may be corrupt. This file will
+ be opened in append mode.
.. option:: read_iolog=str
**slat**
Submission latency (**min** being the minimum, **max** being the
maximum, **avg** being the average, **stdev** being the standard
- deviation). This is the time it took to submit the I/O. For
- sync I/O this row is not displayed as the slat is really the
- completion latency (since queue/complete is one operation there).
- This value can be in nanoseconds, microseconds or milliseconds ---
- fio will choose the most appropriate base and print that (in the
- example above nanoseconds was the best scale). Note: in :option:`--minimal` mode
- latencies are always expressed in microseconds.
+ deviation). This is the time from when fio initialized the I/O
+ to submission. For synchronous ioengines this includes the time
+ up until just before the ioengine's queue function is called.
+ For asynchronous ioengines this includes the time up through the
+ completion of the ioengine's queue function (and commit function
+ if it is defined). For sync I/O this row is not displayed as the
+ slat is negligible. This value can be in nanoseconds,
+ microseconds or milliseconds --- fio will choose the most
+ appropriate base and print that (in the example above
+ nanoseconds was the best scale). Note: in :option:`--minimal`
+ mode latencies are always expressed in microseconds.
**clat**
Completion latency. Same names as slat, this denotes the time from
- submission to completion of the I/O pieces. For sync I/O, clat will
- usually be equal (or very close) to 0, as the time from submit to
- complete is basically just CPU time (I/O has already been done, see slat
- explanation).
+ submission to completion of the I/O pieces. For sync I/O, this
+ represents the time from when the I/O was submitted to the
+ operating system to when it was completed. For asynchronous
+ ioengines this is the time from when the ioengine's queue (and
+ commit if available) functions were completed to when the I/O's
+ completion was reaped by fio.
**lat**
Total latency. Same names as slat and clat, this denotes the time from
when fio created the I/O unit to completion of the I/O operation.
+ It is the sum of submission and completion latency.
**bw**
Bandwidth statistics based on samples. Same names as the xlat stats,
projects / fio.git / blobdiff