The following changes since commit 3dd2e8aa0519225da5ccc100aa02e55306bcc2f3:
fix to replay_align on iolog previous code was rejecting all positive alignment values and only accepting align to 0 value, opposite of what it should be doing (2017-02-02 10:37:00 -0800)
are available in the git repository at:
git://git.kernel.dk/fio.git master
for you to fetch changes up to 9d25d068f88f1be7ce4e67654ee26f8faa1ebca4:
doc: minor HOWTO fixes (2017-02-04 10:25:58 +0000)
----------------------------------------------------------------
Sitsofe Wheeler (1):
doc: minor HOWTO fixes
HOWTO | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
---
Diff of recent changes:
diff --git a/HOWTO b/HOWTO
index 295dc10..f44c626 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1061,7 +1061,8 @@ I/O type
Start I/O at the given offset in the file. The data before the given offset
will not be touched. This effectively caps the file size at `real_size -
- offset`.
+ offset`. Can be combined with :option:`size` to constrain the start and
+ end range that I/O will be done within.
.. option:: offset_increment=int
@@ -1505,6 +1506,8 @@ I/O size
files or devices. If the files do not exist, size must be given. It is also
possible to give size as a percentage between 1 and 100. If ``size=20%`` is
given, fio will use 20% of the full size of the given files or devices.
+ Can be combined with :option:`offset` to constrain the start and end range
+ that I/O will be done within.
.. option:: io_size=int, io_limit=int
@@ -1679,7 +1682,7 @@ I/O engine
files based on the offset generated by fio backend. (see the example
job file to create such files, use ``rw=write`` option). Please
note, you might want to set necessary environment variables to work
- with hdfs/libhdfs properly. Each jobs uses it's own connection to
+ with hdfs/libhdfs properly. Each job uses its own connection to
HDFS.
**mtd**
@@ -1721,7 +1724,7 @@ caveat that when used on the command line, they must come after the
reap events. The reaping mode is only enabled when polling for a minimum of
0 events (e.g. when :option:`iodepth_batch_complete` `=0`).
-.. option:: hipri : [psyncv2]
+.. option:: hipri : [pvsync2]
Set RWF_HIPRI on I/O, indicating to the kernel that it's of higher priority
than normal.
@@ -2889,7 +2892,7 @@ Interpreting the output
Fio spits out a lot of output. While running, fio will display the status of the
jobs created. An example of that would be::
- Jobs: 1: [_r] [24.8% done] [r=20992KiB/s,w=24064KiB/s,t=0KiB/s] [r=82,w=94,t=0 iops] [eta 00h:01m:31s]
+ Jobs: 1 (f=1): [_(1),M(1)][24.8%][r=20.5MiB/s,w=23.5MiB/s][r=82,w=94 IOPS][eta 01m:31s]
The characters inside the square brackets denote the current status of each
thread. The possible values (in typical life cycle order) are:
@@ -2934,14 +2937,15 @@ Fio will condense the thread string as not to take up more space on the command
line as is needed. For instance, if you have 10 readers and 10 writers running,
the output would look like this::
- Jobs: 20 (f=20): [R(10),W(10)] [4.0% done] [r=20992KiB/s,w=24064KiB/s,t=0KiB/s] [r=82,w=94,t=0 iops] [eta 57m:36s]
+ Jobs: 20 (f=20): [R(10),W(10)][4.0%][r=20.5MiB/s,w=23.5MiB/s][r=82,w=94 IOPS][eta 57m:36s]
Fio will still maintain the ordering, though. So the above means that jobs 1..10
are readers, and 11..20 are writers.
The other values are fairly self explanatory -- number of threads currently
-running and doing I/O, rate of I/O since last check (read speed listed first,
-then write speed), and the estimated completion percentage and time for the
+running and doing I/O, the number of currently open files (f=), the rate of I/O
+since last check (read speed listed first, then write speed and optionally trim
+speed), and the estimated completion percentage and time for the current
running group. It's impossible to estimate runtime of the following groups (if
any). Note that the string is displayed in order, so it's possible to tell which
of the jobs are currently doing what. The first character is the first job
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
