From: Juergen Salk <juergen.salk@uni-ulm.de>
To: Jens Axboe <axboe@kernel.dk>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Amount of data read with mixed workload sequential/random with percentage_random set
Date: Wed, 25 Sep 2013 22:58:17 +0200 [thread overview]
Message-ID: <20130925205817.GD20577@highx.de> (raw)
In-Reply-To: <52434212.6050404@kernel.dk>
* Jens Axboe <axboe@kernel.dk> [130925 14:05]:
> > Hi,
> >
> > I'm still a bit puzzled about the amount of data read by
> > individual processes spawned by fio. Given the following (now
> > simplified) job file:
> >
> > --- snip ---
> > [global]
> > ioengine=sync
> > direct=0
> > bssplit=19k/25:177k/15:350k/60
> > size=100m
> > numjobs=4
> > directory=/tmp
> >
> > [work]
> > rw=randread
> > --- snip ---
> >
> > $ fio jobfile.fio >fio.out
> > $ grep io= fio.out
> > read : io=199968KB, bw=4892.6KB/s, iops=27, runt= 40872msec
> > read : io=200062KB, bw=5083.5KB/s, iops=28, runt= 39359msec
> > read : io=200156KB, bw=4989.1KB/s, iops=27, runt= 40112msec
> > read : io=199940KB, bw=4492.4KB/s, iops=24, runt= 44507msec
> > READ: io=800126KB, aggrb=17977KB/s, minb=4492KB/s, maxb=5083KB/s, mint=39359msec, maxt=44507msec
> >
> > I.e. every individual process reads approx. 200 MB of data rather
> > than 100 MB as specified in the job file. For sequential reads
> > (i.e. replaced rw=randread by rw=read, but otherwise unchanged job
> > file) the amount of data read by each process is close to 100 MB as
> > expected.
> >
> > I am probably missing something obvious, but why does the job file
> > above result in 200 MB read by every process?
>
> It should not, that's definitely a bug. I'm guessing it's triggered by
> the strange block sizes being used. Can you see if adding:
>
> random_generator=lfsr
>
> helps?
Thanks for your response, Jens. Yes it does. It's a bit confusing
though, as the man page says "LFSR only works with single block
sizes, not with workloads that use multiple block sizes. If used
with such a workload, fio may read or write some blocks multiple
times." Shouldn't this be read as "Don't use LFSR with mixed
block sizes."?
I am sorry to keep on harping on the matter, but I am planning to
use fio for simulating file sizes where total runtime will
become a serious issue. And these simulations will definitely
involve strange mixed block sizes ...
Thanks again.
Best regards,
Juergen
next prev parent reply other threads:[~2013-09-25 20:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 14:58 Amount of data read with mixed workload sequential/random with percentage_random set Juergen Salk
2013-09-24 19:55 ` Juergen Salk
2013-09-25 20:05 ` Jens Axboe
2013-09-25 20:58 ` Juergen Salk [this message]
2013-09-25 21:01 ` Jens Axboe
2013-10-10 5:47 ` Juergen Salk
2013-10-23 8:54 ` Jens Axboe
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=20130925205817.GD20577@highx.de \
--to=juergen.salk@uni-ulm.de \
--cc=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox