X-Git-Url: https://git.kernel.dk/?p=fio.git;a=blobdiff_plain;f=HOWTO;h=15ee367b57ea1ea4a907d33a7fab77c01c5905b2;hp=66ebebe8579dd5954e574bf016c31b5fbd0e5baf;hb=179446e0122d04ddbeb3d353ff68350490b0841c;hpb=47d85e2bd4763204a983c7bf4833c0d466dc36ca

diff --git a/HOWTO b/HOWTO
index 66ebebe8..15ee367b 100644
--- a/HOWTO
+++ b/HOWTO
@@ -336,6 +336,12 @@ bs_unaligned	If this option is given, any byte size value within bsrange
 zero_buffers	If this option is given, fio will init the IO buffers to
 		all zeroes. The default is to fill them with random data.
 
+refill_buffers	If this option is given, fio will refill the IO buffers
+		on every submit. The default is to only fill it at init
+		time and reuse that data. Only makes sense if zero_buffers
+		isn't specified, naturally. If data verification is enabled,
+		refill_buffers is also automatically enabled.
+
 nrfiles=int	Number of files to use for this job. Defaults to 1.
 
 openfiles=int	Number of files to keep open at the same time. Defaults to
@@ -454,7 +460,11 @@ fsync=int	If writing to a file, issue a sync of the dirty data
 		not sync the file. The exception is the sg io engine, which
 		synchronizes the disk cache anyway.
 
-overwrite=bool	If writing to a file, setup the file first and do overwrites.
+overwrite=bool	If true, writes to a file will always overwrite existing
+		data. If the file doesn't already exist, it will be
+		created before the write phase begins. If the file exists
+		and is large enough for the specified write phase, nothing
+		will be done.
 
 end_fsync=bool	If true, fsync file contents when the job exits.
 
@@ -462,10 +472,6 @@ fsync_on_close=bool	If true, fio will fsync() a dirty file on close.
 		This differs from end_fsync in that it will happen on every
 		file close, not just at the end of the job.
 
-rwmixcycle=int	Value in milliseconds describing how often to switch between
-		reads and writes for a mixed workload. The default is
-		500 msecs.
-
 rwmixread=int	How large a percentage of the mix should be reads.
 
 rwmixwrite=int	How large a percentage of the mix should be writes. If both
@@ -818,6 +824,8 @@ Client1 (g=0): err= 0:
     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, 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%
+     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
+     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=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%,
      lat (msec): 250=15.2%, 500=0.0%, 750=0.0%, 1000=0.0%, >=2048=0.0%
@@ -855,6 +863,11 @@ IO depths=	The distribution of io depths over the job life time. The
 		16= entries includes depths up to that value but higher
 		than the previous entry. In other words, it covers the
 		range from 16 to 31.
+IO submit=	How many pieces of IO were submitting in a single submit
+		call. Each entry denotes that amount and below, until
+		the previous entry - eg, 8=100% mean that we submitted
+		anywhere in between 5-8 ios per submit call.
+IO complete=	Like the above submit number, but for completions instead.
 IO issued=	The number of read/write requests issued, and how many
 		of them were short.
 IO latencies=	The distribution of IO completion latencies. This is the