Add crc16 verify type

[fio.git] / HOWTO

diff --git a/HOWTO b/HOWTO
index 7e706aba1481e68c97fbb66e57a85ccc28649b8c..e693d7aec21da5678f236d72bf8d81a20ee8684c 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -343,6 +343,9 @@ ioengine=str        Defines how the job issues io to the file. The following
                                or receive, if the latter only the port
                                argument is used.
 
+                       netsplice Like net, but uses splice/vmsplice to
+                               map data and send/receive.
+
                        cpu     Doesn't transfer any data, but burns CPU
                                cycles according to the cpuload= and
                                cpucycle= options. Setting cpuload=85
@@ -472,6 +475,10 @@ cpumask=int        Set the CPU affinity of this job. The parameter given is a
                sched_setaffinity(2). This may not work on all supported
                operating systems or kernel versions.
 
+cpus_allowed=str Controls the same options as cpumask, but it allows a text
+               setting of the permitted CPUs instead. So to use CPUs 1 and
+               5, you would specify cpus_allowed=1,5.
+
 startdelay=int Start this job the specified number of seconds after fio
                has started. Only useful if the job file contains several
                jobs, and you want to delay starting some jobs to a certain
@@ -570,6 +577,9 @@ verify=str  If writing to a file, fio can verify the file contents
                        crc32   Use a crc32 sum of the data area and store
                                it in the header of each block.
 
+                       crc16   Use a crc16 sum of the data area and store
+                               it in the header of each block.
+
                        null    Only pretend to verify. Useful for testing
                                internals with ioengine=null, not for much
                                else.
@@ -690,9 +700,10 @@ E          Thread exited, not reaped by main thread yet.
 _              Thread reaped.
 
 The other values are fairly self explanatory - number of threads
-currently running and doing io, rate of io since last check, and the estimated
-completion percentage and time for the running group. It's impossible to
-estimate runtime of the following groups (if any).
+currently running and doing io, rate of io since last check (read speed
+listed first, then write speed), and the estimated completion percentage
+and time for the running group. It's impossible to estimate runtime of
+the following groups (if any).
 
 When fio is done (or interrupted by ctrl-c), it will show the data for
 each thread, group of threads, and disks in that order. For each data
@@ -719,7 +730,10 @@ runt=              The runtime of that thread
        slat=   Submission latency (avg being the average, stdev being the
                standard deviation). This is the time it took to submit
                the io. For sync io, the slat is really the completion
-               latency, since queue/complete is one operation there.
+               latency, since queue/complete is one operation there. This
+               value can be in miliseconds or microseconds, fio will choose
+               the most appropriate base and print that. In the example
+               above, miliseconds is the best scale.
        clat=   Completion latency. Same names as slat, this denotes the
                time from submission to completion of the io pieces. For
                sync io, clat will usually be equal (or very close) to 0,