From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from merlin.infradead.org ([205.233.59.134]:48910 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751101AbdBENAI (ORCPT ); Sun, 5 Feb 2017 08:00:08 -0500 Received: from [216.160.245.99] (helo=kernel.dk) by merlin.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1caMQJ-0004QU-7T for fio@vger.kernel.org; Sun, 05 Feb 2017 13:00:07 +0000 Subject: Recent changes (master) From: Jens Axboe Message-Id: <20170205130002.753DA2C2080@kernel.dk> Date: Sun, 5 Feb 2017 06:00:02 -0700 (MST) Sender: fio-owner@vger.kernel.org List-Id: fio@vger.kernel.org To: fio@vger.kernel.org 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