.. 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
**write**
Sequential writes.
**trim**
- Sequential trims (Linux block devices only).
+ Sequential trims (Linux block devices and SCSI
+ character devices only).
**randread**
Random reads.
**randwrite**
Random writes.
**randtrim**
- Random trims (Linux block devices only).
+ Random trims (Linux block devices and SCSI
+ character devices only).
**rw,readwrite**
Sequential mixed reads and writes.
**randrw**
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
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.
ioctl, or if the target is an sg character device we use
:manpage:`read(2)` and :manpage:`write(2)` for asynchronous
I/O. Requires :option:`filename` option to specify either block or
- character devices.
+ character devices. This engine supports trim operations.
The sg engine includes engine specific options.
**null**
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
~~~~~~~~~
replay, the file needs to be turned into a blkparse binary data file first
(``blkparse <device> -o /dev/null -d file_for_fio.bin``).
+.. option:: read_iolog_chunked=bool
+
+ Determines how iolog is read. If false(default) entire :option:`read_iolog`
+ will be read at once. If selected true, input from iolog will be read
+ gradually. Useful when iolog is very large, or it is generated.
+
.. option:: replay_no_stall=bool
When replaying I/O with :option:`read_iolog` the default behavior is to
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
projects / fio.git / blobdiff