X-Git-Url: https://git.kernel.dk/?p=fio.git;a=blobdiff_plain;f=HOWTO;h=8cb849c7c6edad0ddf70294d98f3084cd2894a5a;hp=99cbaea37eb760dca27875eab9bcb8bd9def2292;hb=546a9142511875524850ac92776184fd9fb7196e;hpb=7616cafe9c2c76451e518eafe5cc37db460c8b1e

diff --git a/HOWTO b/HOWTO
index 99cbaea3..8cb849c7 100644
--- 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
@@ -466,10 +469,16 @@ ratecycle=int	Average bandwidth for 'rate' and 'ratemin' over this number
 		of milliseconds.
 
 cpumask=int	Set the CPU affinity of this job. The parameter given is a
-		bitmask of allowed CPU's the job may run on. See man
+		bitmask of allowed CPU's the job may run on. So if you want
+		the allowed CPUs to be 1 and 5, you would pass the decimal
+		value of (1 << 1 | 1 << 5), or 34. See man
 		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
@@ -565,9 +574,19 @@ verify=str	If writing to a file, fio can verify the file contents
 			md5	Use an md5 sum of the data area and store
 				it in the header of each block.
 
+			crc64	Use an experimental crc64 sum of the data
+				area and store it in the header of each
+				block.
+
 			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.
+
+			crc7	Use a crc7 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.
@@ -583,6 +602,15 @@ verifysort=bool	If set, fio will sort written verify blocks when it deems
 		can ignore this option unless doing huge amounts of really
 		fast IO where the red-black tree sorting CPU time becomes
 		significant.
+
+header_offset=siint	Swap the verification header with data somewhere else
+			in the block before writing. Its swapped back before
+			verifying.
+
+header_interval=siint	Write the verification header at a finer granularity
+			than the blocksize. It will be written for chunks the
+			size of header_interval. blocksize should divide this
+			evenly.
 		
 stonewall	Wait for preceeding jobs in the job file to exit, before
 		starting this one. Can be used to insert serialization
@@ -688,9 +716,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
@@ -717,7 +746,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,