Allow reset of offset_increment counter
[fio.git] / HOWTO
diff --git a/HOWTO b/HOWTO
index 3001fe74a0b6cffe19fba612e95c082580085c01..1c4b308cf3df9bd33d75306cb3e0e2dfd8df4a40 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -736,11 +736,12 @@ offset=int        Start io at the given offset in the file. The data before
                caps the file size at real_size - offset.
 
 offset_increment=int   If this is provided, then the real offset becomes
-               the offset + offset_increment * thread_number, where the
-               thread number is a counter that starts at 0 and is incremented
-               for each job. This option is useful if there are several jobs
-               which are intended to operate on a file in parallel in disjoint
-               segments, with even spacing between the starting points.
+               offset + offset_increment * thread_number, where the thread
+               number is a counter that starts at 0 and is incremented for
+               each sub-job (i.e. when numjobs option is specified). This
+               option is useful if there are several jobs which are intended
+               to operate on a file in parallel disjoint segments, with
+               even spacing between the starting points.
 
 number_ios=int Fio will normally perform IOs until it has exhausted the size
                of the region set by size=, or if it exhaust the allocated
@@ -1307,7 +1308,9 @@ write_bw_log=str If given, write a bandwidth log of the jobs in this job
                jobs in their lifetime. The included fio_generate_plots
                script uses gnuplot to turn these text files into nice
                graphs. See write_lat_log for behaviour of given
-               filename. For this option, the suffix is _bw.log.
+               filename. For this option, the suffix is _bw.x.log, where
+               x is the index of the job (1..N, where N is the number of
+               jobs).
 
 write_lat_log=str Same as write_bw_log, except that this option stores io
                submission, completion, and total latencies instead. If no
@@ -1317,14 +1320,16 @@ 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_clat.log,
-               and foo_lat.log. This helps fio_generate_plot fine the logs
-               automatically.
+               The actual log names will be foo_slat.x.log, foo_clat.x.log,
+               and foo_lat.x.log, where x is the index of the job (1..N,
+               where N is the number of jobs). This helps fio_generate_plot
+               fine the logs automatically.
 
 write_iops_log=str Same as write_bw_log, but writes IOPS. If no filename is
                given with this option, the default filename of
-               "jobname_type.log" is used. Even if the filename is given,
-               fio will still append the type of log.
+               "jobname_type.x.log" is used,where x is the index of the job
+               (1..N, where N is the number of jobs). Even if the filename
+               is given, fio will still append the type of log.
 
 log_avg_msec=int By default, fio will log an entry in the iops, latency,
                or bw log for every IO that completes. When writing to the
@@ -1336,6 +1341,26 @@ log_avg_msec=int By default, fio will log an entry in the iops, latency,
 log_offset=int If this is set, the iolog options will include the byte
                offset for the IO entry as well as the other data values.
 
+log_compression=int    If this is set, fio will compress the IO logs as
+               it goes, to keep the memory footprint lower. When a log
+               reaches the specified size, that chunk is removed and
+               compressed in the background. Given that IO logs are
+               fairly highly compressible, this yields a nice memory
+               savings for longer runs. The downside is that the
+               compression will consume some background CPU cycles, so
+               it may impact the run. This, however, is also true if
+               the logging ends up consuming most of the system memory.
+               So pick your poison. The IO logs are saved normally at the
+               end of a run, by decompressing the chunks and storing them
+               in the specified log file. This feature depends on the
+               availability of zlib.
+
+log_store_compressed=bool      If set, and log_compression is also set,
+               fio will store the log files in a compressed format. They
+               can be decompressed with fio, using the --inflate-log
+               command line parameter. The files will be stored with a
+               .fz suffix.
+
 lockmem=int    Pin down the specified amount of memory with mlock(2). Can
                potentially be used instead of removing memory or booting
                with less memory to simulate a smaller amount of memory.