Android: Fix the build of the 'sg' engine
[fio.git] / HOWTO.rst
index 28ac2b7c9130f58a032d0af6d247afefcfd20f5a..e89d05f04791d22d9369aa9466b48d5e86dfc1ab 100644 (file)
--- a/HOWTO.rst
+++ b/HOWTO.rst
@@ -167,9 +167,9 @@ Command line options
        defined by `ioengine`.  If no `ioengine` is given, list all
        available ioengines.
 
-.. option:: --showcmd=jobfile
+.. option:: --showcmd
 
-       Convert `jobfile` to a set of command-line options.
+       Convert given job files to a set of command-line options.
 
 .. option:: --readonly
 
@@ -1129,7 +1129,14 @@ I/O type
                                Random mixed reads and writes.
                **trimwrite**
                                Sequential trim+write sequences. Blocks will be trimmed first,
-                               then the same blocks will be written to.
+                               then the same blocks will be written to. So if ``io_size=64K``
+                               is specified, Fio will trim a total of 64K bytes and also
+                               write 64K bytes on the same trimmed blocks. This behaviour
+                               will be consistent with ``number_ios`` or other Fio options
+                               limiting the total bytes or number of I/O's.
+               **randtrimwrite**
+                               Like trimwrite, but uses random offsets rather
+                               than sequential writes.
 
        Fio defaults to read if the option is not specified.  For the mixed I/O
        types, the default is to split them 50/50.  For certain types of I/O the
@@ -1301,7 +1308,7 @@ I/O type
        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%. In ZBD mode, value can be set as 
+       for example, ``offset=20%`` to specify 20%. In ZBD mode, value can be set as
         number of zones using 'z'.
 
 .. option:: offset_align=int
@@ -1877,7 +1884,7 @@ I/O size
        If this option is not specified, fio will use the full size of the given
        files or devices.  If the files do not exist, size must be given. It is also
        possible to give size as a percentage between 1 and 100. If ``size=20%`` is
-       given, fio will use 20% of the full size of the given files or devices. 
+       given, fio will use 20% of the full size of the given files or devices.
        In ZBD mode, value can also be set as number of zones using 'z'.
        Can be combined with :option:`offset` to constrain the start and end range
        that I/O will be done within.
@@ -2550,7 +2557,7 @@ with the caveat that when used on the command line, they must come after the
 
    [dfs]
 
-       Specificy a different chunk size (in bytes) for the dfs file.
+       Specify a different chunk size (in bytes) for the dfs file.
        Use DAOS container's chunk size by default.
 
    [libhdfs]
@@ -2559,7 +2566,7 @@ with the caveat that when used on the command line, they must come after the
 
 .. option:: object_class=str : [dfs]
 
-       Specificy a different object class for the dfs file.
+       Specify a different object class for the dfs file.
        Use DAOS container's object class by default.
 
 .. option:: skip_bad=bool : [mtd]
@@ -2692,6 +2699,20 @@ with the caveat that when used on the command line, they must come after the
 
        The S3 key/access id.
 
+.. option:: http_s3_sse_customer_key=str : [http]
+
+        The encryption customer key in SSE server side.
+
+.. option:: http_s3_sse_customer_algorithm=str : [http]
+
+        The encryption customer algorithm in SSE server side.
+        Default is **AES256**
+
+.. option:: http_s3_storage_class=str : [http]
+
+        Which storage class to access. User-customizable settings.
+        Default is **STANDARD**
+
 .. option:: http_swift_auth_token=str : [http]
 
        The Swift auth token. See the example configuration file on how
@@ -2766,41 +2787,56 @@ with the caveat that when used on the command line, they must come after the
        Select the xnvme async command interface. This can take these values.
 
        **emu**
-               This is default and used to emulate asynchronous I/O.
+               This is default and use to emulate asynchronous I/O by using a
+               single thread to create a queue pair on top of a synchronous
+               I/O interface using the NVMe driver IOCTL.
        **thrpool**
-               Use thread pool for Asynchronous I/O.
+               Emulate an asynchronous I/O interface with a pool of userspace
+               threads on top of a synchronous I/O interface using the NVMe
+               driver IOCTL. By default four threads are used.
        **io_uring**
-               Use Linux io_uring/liburing for Asynchronous I/O.
+               Linux native asynchronous I/O interface which supports both
+               direct and buffered I/O.
+       **io_uring_cmd**
+               Fast Linux native asynchronous I/O interface for NVMe pass
+               through commands. This only works with NVMe character device
+               (/dev/ngXnY).
        **libaio**
                Use Linux aio for Asynchronous I/O.
        **posix**
-               Use POSIX aio for Asynchronous I/O.
+               Use the posix asynchronous I/O interface to perform one or
+               more I/O operations asynchronously.
        **nil**
-               Use nil-io; For introspective perf. evaluation
+               Do not transfer any data; just pretend to. This is mainly used
+               for introspective performance evaluation.
 
 .. option:: xnvme_sync=str : [xnvme]
 
        Select the xnvme synchronous command interface. This can take these values.
 
        **nvme**
-               This is default and uses Linux NVMe Driver ioctl() for synchronous I/O.
+               This is default and uses Linux NVMe Driver ioctl() for
+               synchronous I/O.
        **psync**
-               Use pread()/write() for synchronous I/O.
+               This supports regular as well as vectored pread() and pwrite()
+               commands.
+       **block**
+               This is the same as psync except that it also supports zone
+               management commands using Linux block layer IOCTLs.
 
 .. option:: xnvme_admin=str : [xnvme]
 
        Select the xnvme admin command interface. This can take these values.
 
        **nvme**
-               This is default and uses linux NVMe Driver ioctl() for admin commands.
+               This is default and uses linux NVMe Driver ioctl() for admin
+               commands.
        **block**
                Use Linux Block Layer ioctl() and sysfs for admin commands.
-       **file_as_ns**
-               Use file-stat to construct NVMe idfy responses.
 
 .. option:: xnvme_dev_nsid=int : [xnvme]
 
-       xnvme namespace identifier, for userspace NVMe driver.
+       xnvme namespace identifier for userspace NVMe driver, such as SPDK.
 
 .. option:: xnvme_iovec=int : [xnvme]
 
@@ -3049,7 +3085,8 @@ I/O replay
 
        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
 
@@ -3897,6 +3934,13 @@ Error handling
        appended, the total error count and the first error. The error field given
        in the stats is the first error that was hit during the run.
 
+       Note: a write error from the device may go unnoticed by fio when using
+       buffered IO, as the write() (or similar) system call merely dirties the
+       kernel pages, unless :option:`sync` or :option:`direct` is used. Device IO
+       errors occur when the dirty data is actually written out to disk. If fully
+       sync writes aren't desirable, :option:`fsync` or :option:`fdatasync` can be
+       used as well. This is specific to writes, as reads are always synchronous.
+
        The allowed values are:
 
                **none**
@@ -4165,24 +4209,31 @@ writes in the example above).  In the order listed, they denote:
 **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,