X-Git-Url: https://git.kernel.dk/?p=fio.git;a=blobdiff_plain;f=HOWTO;h=d5fb52cfb0f9f931db588c78d92e81a95480f2ca;hp=e693d7aec21da5678f236d72bf8d81a20ee8684c;hb=e7d2e61694c62b90a2fb84c012b4edcc1973d72c;hpb=969f7ed32353ade93ea30542a4993b75b94e3f8a

diff --git a/HOWTO b/HOWTO
index e693d7ae..d5fb52cf 100644
--- a/HOWTO
+++ b/HOWTO
@@ -170,7 +170,8 @@ Some parameters take an option of a given type, such as an integer or
 a string. The following types are used:
 
 str	String. This is a sequence of alpha characters.
-int	Integer. A whole number value, can be negative.
+int	Integer. A whole number value, can be negative. If prefixed with
+	0x, the integer is assumed to be of base 16 (hexidecimal).
 siint	SI integer. A whole number value, which may contain a postfix
 	describing the base of the number. Accepted postfixes are k/m/g,
 	meaning kilo, mega, and giga. So if you want to specify 4096,
@@ -313,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.
@@ -346,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
@@ -568,18 +571,45 @@ 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:
 
 			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.
+
+			sha512	Use sha512 as the checksum function.
+
+			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.
@@ -595,6 +625,20 @@ 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.
+
+verify_offset=siint	Swap the verification header with data somewhere else
+			in the block before writing. Its swapped back before
+			verifying.
+
+verify_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.
+
+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
@@ -714,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%,
@@ -745,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
@@ -815,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