Remove comment wrt sigaction() usage, it's deprecated
[fio.git] / HOWTO
diff --git a/HOWTO b/HOWTO
index 569b998f215b78d41a36ac71d78f1506a013af4e..12974f3f4dcc563cd143a1084aaff17116d70d48 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -219,6 +219,25 @@ filename=str       Fio normally makes up a filename based on the job name,
 opendir=str    Tell fio to recursively add any file it can find in this
                directory and down the file system tree.
 
+lockfile=str   Fio defaults to not doing any locking files before it does
+               IO to them. If a file or file descriptor is shared, fio
+               can serialize IO to that file to make the end result
+               consistent. This is usual for emulating real workloads that
+               share files. The lock modes are:
+
+                       none            No locking. The default.
+                       exclusive       Only one thread/process may do IO,
+                                       excluding all others.
+                       readwrite       Read-write locking on the file. Many
+                                       readers may access the file at the
+                                       same time, but writes get exclusive
+                                       access.
+
+               The option may be post-fixed with a lock batch number. If
+               set, then each thread/process may do that amount of IOs to
+               the file before giving up the lock. Since lock acqusition is
+               expensive, batching the lock/unlocks will speed up IO.
+
 readwrite=str
 rw=str         Type of io pattern. Accepted values are:
 
@@ -262,6 +281,10 @@ filesize=siint     Individual file sizes. May be a range, in which case fio
                and limited to 'size' in total (if that is given). If not
                given, each created file is the same size.
 
+fill_device=bool Sets size to something really large and waits for ENOSPC (no
+               space left on device) as the terminating condition. Only makes
+                sense with sequential write.
+
 blocksize=siint
 bs=siint       The block size used for the io units. Defaults to 4k. Values
                can be given for both read and writes. If a single siint is
@@ -313,6 +336,12 @@ bs_unaligned       If this option is given, any byte size value within bsrange
 zero_buffers   If this option is given, fio will init the IO buffers to
                all zeroes. The default is to fill them with random data.
 
+refill_buffers If this option is given, fio will refill the IO 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.
+
 nrfiles=int    Number of files to use for this job. Defaults to 1.
 
 openfiles=int  Number of files to keep open at the same time. Defaults to
@@ -340,10 +369,14 @@ ioengine=str      Defines how the job issues io to the file. The following
 
                        psync   Basic pread(2) or pwrite(2) io.
 
+                       vsync   Basic readv(2) or writev(2) IO.
+
                        libaio  Linux native asynchronous io.
 
                        posixaio glibc posix asynchronous io.
 
+                       solarisaio Solaris native asynchronous io.
+
                        mmap    File is memory mapped and data copied
                                to/from using memcpy(3).
 
@@ -377,7 +410,10 @@ ioengine=str       Defines how the job issues io to the file. The following
                                cycles according to the cpuload= and
                                cpucycle= options. Setting cpuload=85
                                will cause that job to do nothing but burn
-                               85% of the CPU.
+                               85% of the CPU. In case of SMP machines,
+                               use numjobs=<no_of_cpu> to get desired CPU
+                               usage, as the cpuload only loads a single
+                               CPU at the desired rate.
 
                        guasi   The GUASI IO engine is the Generic Userspace
                                Asyncronous Syscall Interface approach
@@ -398,8 +434,9 @@ iodepth=int This defines how many io units to keep in flight against
                concurrency.
 
 iodepth_batch=int This defines how many pieces of IO to submit at once.
-               It defaults to the same as iodepth, but can be set lower
-               if one so desires.
+               It defaults to 1 which means that we submit each IO
+               as soon as it is available, but can be raised to submit
+               bigger batches of IO at the time.
 
 iodepth_low=int        The low water mark indicating when to start filling
                the queue again. Defaults to the same as iodepth, meaning
@@ -425,7 +462,11 @@ fsync=int  If writing to a file, issue a sync of the dirty data
                not sync the file. The exception is the sg io engine, which
                synchronizes the disk cache anyway.
 
-overwrite=bool If writing to a file, setup the file first and do overwrites.
+overwrite=bool If true, writes to a file will always overwrite existing
+               data. If the file doesn't already exist, it will be
+               created before the write phase begins. If the file exists
+               and is large enough for the specified write phase, nothing
+               will be done.
 
 end_fsync=bool If true, fsync file contents when the job exits.
 
@@ -433,10 +474,6 @@ fsync_on_close=bool        If true, fio will fsync() a dirty file on close.
                This differs from end_fsync in that it will happen on every
                file close, not just at the end of the job.
 
-rwmixcycle=int Value in milliseconds describing how often to switch between
-               reads and writes for a mixed workload. The default is
-               500 msecs.
-
 rwmixread=int  How large a percentage of the mix should be reads.
 
 rwmixwrite=int How large a percentage of the mix should be writes. If both
@@ -453,6 +490,12 @@ norandommap        Normally fio will cover every block of the file when doing
                fio doesn't track potential block rewrites which may alter
                the calculated checksum for that block.
 
+softrandommap  See norandommap. If fio runs with the random block map enabled
+               and it fails to allocate the map, if this option is set it
+               will continue without a random block map. As coverage will
+               not be as complete as with random maps, this option is
+               disabled by default.
+
 nice=int       Run the job with the given nice value. See man nice(2).
 
 prio=int       Set the io priority value of this job. Linux limits us to
@@ -625,15 +668,6 @@ verify=str If writing to a file, fio can verify the file contents
                                (timestamp, block number etc.). The block
                                number is verified.
 
-                       pattern Fill the IO buffers with a specific pattern,
-                               that we can use to verify. Depending on the
-                               width of the pattern, fio will fill 1/2/3/4
-                               bytes of the buffer at the time. The pattern
-                               cannot be larger than a 32-bit quantity. The
-                               given pattern is given as a postfix to this
-                               option, ala: verify=pattern:0x5a. It accepts
-                               both hex and dec values.
-
                        null    Only pretend to verify. Useful for testing
                                internals with ioengine=null, not for much
                                else.
@@ -659,6 +693,14 @@ verify_interval=siint      Write the verification header at a finer granularity
                        size of header_interval. blocksize should divide this
                        evenly.
 
+verify_pattern=int     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.
+
 verify_fatal=bool      Normally fio will keep checking the entire contents
                before quitting on a block verification failure. If this
                option is set, fio will exit the job on the first observed
@@ -784,6 +826,8 @@ Client1 (g=0): err= 0:
     bw (KiB/s) : min=    0, max= 1196, per=51.00%, avg=664.02, stdev=681.68
   cpu        : usr=1.49%, sys=0.25%, ctx=7969, majf=0, minf=17
   IO depths    : 1=0.1%, 2=0.3%, 4=0.5%, 8=99.0%, 16=0.0%, 32=0.0%, >32=0.0%
+     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
+     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
      issued r/w: total=0/32768, short=0/0
      lat (msec): 2=1.6%, 4=0.0%, 10=3.2%, 20=12.8%, 50=38.4%, 100=24.8%,
      lat (msec): 250=15.2%, 500=0.0%, 750=0.0%, 1000=0.0%, >=2048=0.0%
@@ -821,6 +865,11 @@ IO depths= The distribution of io depths over the job life time. The
                16= entries includes depths up to that value but higher
                than the previous entry. In other words, it covers the
                range from 16 to 31.
+IO submit=     How many pieces of IO were submitting in a single submit
+               call. Each entry denotes that amount and below, until
+               the previous entry - eg, 8=100% mean that we submitted
+               anywhere in between 5-8 ios per submit call.
+IO complete=   Like the above submit number, but for completions instead.
 IO issued=     The number of read/write requests issued, and how many
                of them were short.
 IO latencies=  The distribution of IO completion latencies. This is the