->getevents() should take unsigned args

[fio.git] / HOWTO

diff --git a/HOWTO b/HOWTO
index 21ba96033c283d0742f9191cc76ef97cf969277d..d5fb52cfb0f9f931db588c78d92e81a95480f2ca 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -314,6 +314,8 @@ ioengine=str        Defines how the job issues io to the file. The following
                        sync    Basic read(2) or write(2) io. lseek(2) is
                                used to position the io location.
 
+                       psync   Basic pread(2) or pwrite(2) io.
+
                        libaio  Linux native asynchronous io.
 
                        posixaio glibc posix asynchronous io.
@@ -347,7 +349,7 @@ ioengine=str        Defines how the job issues io to the file. The following
                        netsplice Like net, but uses splice/vmsplice to
                                map data and send/receive.
 
-                       cpu     Doesn't transfer any data, but burns CPU
+                       cpuio   Doesn't transfer any data, but burns CPU
                                cycles according to the cpuload= and
                                cpucycle= options. Setting cpuload=85
                                will cause that job to do nothing but burn
@@ -569,6 +571,9 @@ loops=int   Run the specified number of iterations of this job. Used
                to repeat the same workload a given number of times. Defaults
                to 1.
 
+do_verify=bool Run the verify phase after a write phase. Only makes sense if
+               verify is set. Defaults to 1.
+
 verify=str     If writing to a file, fio can verify the file contents
                after each iteration of the job. The allowed values are:
 
@@ -592,6 +597,19 @@ verify=str If writing to a file, fio can verify the file contents
 
                        sha256  Use sha256 as the checksum function.
 
+                       meta    Write extra information about each io
+                               (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.
@@ -617,13 +635,10 @@ 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
+               failure.
                
 stonewall      Wait for preceeding jobs in the job file to exit, before
                starting this one. Can be used to insert serialization
@@ -743,7 +758,7 @@ Client1 (g=0): err= 0:
     slat (msec): min=    0, max=  136, avg= 0.03, stdev= 1.92
     clat (msec): min=    0, max=  631, avg=48.50, stdev=86.82
     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
+  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%
      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%,
@@ -774,7 +789,9 @@ runt=               The runtime of that thread
                only really useful if the threads in this group are on the
                same disk, since they are then competing for disk access.
 cpu=           CPU usage. User and system time, along with the number
-               of context switches this thread went through.
+               of context switches this thread went through, usage of
+               system and user time, and finally the number of major
+               and minor page faults.
 IO depths=     The distribution of io depths over the job life time. The
                numbers are divided into powers of 2, so for example the
                16= entries includes depths up to that value but higher
@@ -844,7 +861,7 @@ Split up, the format is as follows:
                Submission latency: min, max, mean, deviation
                Completion latency: min, max, mean, deviation
                Bw: min, max, aggregate percentage of total, mean, deviation
-       CPU usage: user, system, context switches
+       CPU usage: user, system, context switches, major faults, minor faults
        IO depths: <=1, 2, 4, 8, 16, 32, >=64
        IO latencies: <=2, 4, 10, 20, 50, 100, 250, 500, 750, 1000, >=2000
        Text description