From: Jens Axboe <axboe@kernel.dk>
To: Michael Mattsson <michael.mattsson@gmail.com>, fio <fio@vger.kernel.org>
Subject: Re: --status-interval output race
Date: Wed, 22 Oct 2014 09:44:53 -0600 [thread overview]
Message-ID: <5447D0F5.7090403@kernel.dk> (raw)
In-Reply-To: <CAE56cDu7ctJfTLbFRUGh+VwyHdJ=_rtLYLL_b-kJ=YmeeGaopA@mail.gmail.com>
On 10/21/2014 05:54 PM, Michael Mattsson wrote:
> Hey,
> I'm trying to get predictable output from --status-interval. I believe
> there's some output racing going on and can't think of a way of
> working around it at this point. Is there a way to redirect
> --status-interval to a separate file and have the summary go to
> --output? That would be useful.
>
> Anyhow.
>
> Attached is a --side-by-side diff by a custom --minimal parser, this
> is the command line used: fio --minimal --direct=1 --group_reporting
> --filesize=100m --norandommap --blocksize=32k --time_based --iodepth=1
> --ramp_time=0 --ioengine=libaio --status-interval=5
> --percentage_random=100 --name=randrw-workload --rw=randrw
> --rwmixread=0 --numjobs=2 --filename=/fut1/rs-dev2_2:/fut2/rs-dev2_2
> --runtime=60 --output fio_w.dat
>
> What happens is that intermittently I get a <1s splurge on the last
> line which is suppose to be final output but it screws up the summary
> fields, more explictly:
>
> Bandwidth KB
> IOPS
> Runtime (ms)
>
> Sometime it happens with this workload but it happens more
> infrequently: fio --minimal --direct=1 --group_reporting
> --filesize=100m --norandommap --blocksize=32k --time_based --iodepth=1
> --ramp_time=0 --ioengine=libaio --status-interval=5
> --percentage_random=100 --name=rainscaler-randrw --rw=randrw
> --rwmixread=100 --numjobs=2 --filename=/fut1/rs-dev2_1:/fut2/rs-dev2_1
> --runtime=60 --output fio_r.dat
>
> What is good to know here is that both these run in parallel as two
> independent fio jobs on the same host if there is some communication
> between fio processes that are run independently on the same host that
> promotes this behavior. I can't use /tmp/fio-dump-status as there will
> be a race between master processes who unlink the file first.
>
> fio-2.1.4 and fio-2.1.13 on CentOS 6.5.
Can you see if it works better if you revert commit 83f7b64ea773?
--
Jens Axboe
next prev parent reply other threads:[~2014-10-22 15:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 23:54 --status-interval output race Michael Mattsson
2014-10-22 15:44 ` Jens Axboe [this message]
2014-10-22 16:19 ` Michael Mattsson
2014-10-22 17:37 ` Sitsofe Wheeler
2014-10-22 18:19 ` Michael Mattsson
2014-10-23 15:17 ` Jens Axboe
2014-10-23 21:54 ` Michael Mattsson
2014-10-24 15:44 ` Michael Mattsson
2014-10-24 15:50 ` Jens Axboe
2014-10-24 19:22 ` Michael Mattsson
2014-10-25 16:24 ` Michael Mattsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5447D0F5.7090403@kernel.dk \
--to=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
--cc=michael.mattsson@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.