X-Git-Url: https://git.kernel.dk/?p=fio.git;a=blobdiff_plain;f=HOWTO;h=794728f3b2cf3b3d9edc3a7493ce157c8a5901ea;hp=c7d0c9e8324b646a637ee9d55e9ebd273a6119a1;hb=4b20c6814d4742e27a68f8a740a955283869fbcd;hpb=8f91cc3f7835cdca84944d456e1da77d44a7c354

diff --git a/HOWTO b/HOWTO
index c7d0c9e8..794728f3 100644
--- a/HOWTO
+++ b/HOWTO
@@ -568,6 +568,8 @@ ioengine=str	Defines how the job issues io to the file. The following
 
 			vsync	Basic readv(2) or writev(2) IO.
 
+			psyncv	Basic preadv(2) or pwritev(2) IO.
+
 			libaio	Linux native asynchronous io. Note that Linux
 				may only support queued behaviour with
 				non-buffered IO (set direct=1 or buffered=0).
@@ -766,6 +768,17 @@ random_distribution=str:float	By default, fio will use a completely uniform
 		random_distribution=zipf:1.2 as the option. If a non-uniform
 		model is used, fio will disable use of the random map.
 
+percentage_random=int	For a random workload, set how big a percentage should
+		be random. This defaults to 100%, in which case the workload
+		is fully random. It can be set from anywhere from 0 to 100.
+		Setting it to 0 would make the workload fully sequential. Any
+		setting in between will result in a random mix of sequential
+		and random IO, at the given percentages.
+	
+percentage_sequential=int	See percentage_random. It is guaranteed that
+		they add up to 100. The later setting has priority, each
+		will adjust the other.
+
 norandommap	Normally fio will cover every block of the file when doing
 		random IO. If this option is given, fio will just get a
 		new random offset without looking at past io history. This
@@ -817,11 +830,15 @@ thinktime_spin=int
 		to sleeping for the rest of the period specified by
 		thinktime.
 
-thinktime_blocks
+thinktime_blocks=int
 		Only valid if thinktime is set - control how many blocks
 		to issue, before waiting 'thinktime' usecs. If not set,
 		defaults to 1 which will make fio wait 'thinktime' usecs
-		after every block.
+		after every block. This effectively makes any queue depth
+		setting redundant, since no more than 1 IO will be queued
+		before we have to complete it and do our thinktime. In
+		other words, this setting effectively caps the queue depth
+		if the latter is larger.
 
 rate=int	Cap the bandwidth used by this job. The number is in bytes/sec,
 		the normal suffix rules apply. You can use rate=500k to limit
@@ -1219,7 +1236,7 @@ write_lat_log=str Same as write_bw_log, except that this option stores io
 
 		write_lat_log=foo
 
-		The actual log names will be foo_slat.log, foo_slat.log,
+		The actual log names will be foo_slat.log, foo_clat.log,
 		and foo_lat.log. This helps fio_generate_plot fine the logs
 		automatically.
 
@@ -1600,6 +1617,9 @@ util=		The disk utilization. A value of 100% means we kept the disk
 
 It is also possible to get fio to dump the current output while it is
 running, without terminating the job. To do that, send fio the USR1 signal.
+You can also get regularly timed dumps by using the --status-interval
+parameter, or by creating a file in /tmp named fio-dump-status. If fio
+sees this file, it will unlink it and dump the current output status.
 
 
 7.0 Terse output
@@ -1721,7 +1741,7 @@ trim       trim the given file from the given 'offset' for 'length' bytes
 
 
 9.0 CPU idleness profiling
-
+--------------------------
 In some cases, we want to understand CPU overhead in a test. For example,
 we test patches for the specific goodness of whether they reduce CPU usage.
 fio implements a balloon approach to create a thread per CPU that runs at