Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Neto, Antonio Jose Rodrigues" <Antonio.Jose.Rodrigues.Neto@netapp.com>
Cc: "fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: Re: Helping to model this workload
Date: Thu, 25 Jul 2013 12:27:34 -0600	[thread overview]
Message-ID: <20130725182734.GH29296@kernel.dk> (raw)
In-Reply-To: <CE16CF2A.12CB3%Antonio.Jose.Rodrigues.Neto@netapp.com>

On Thu, Jul 25 2013, Neto, Antonio Jose Rodrigues wrote:
> 
> On 7/25/13 12:45 PM, "Jens Axboe" <axboe@kernel.dk> wrote:
> 
> >On Tue, Jul 23 2013, Neto, Antonio Jose Rodrigues wrote:
> >> Hi All
> >> 
> >> This is neto from Brazil
> >> 
> >> How are you?
> >> 
> >> I need to model the following workload:
> >> 
> >> Sequential Read % 35.0
> >> Sequential Write % 5.0
> >> Random Read % 50.0
> >> Random Write % 10.0
> >> Random Read Working Set(GB) 1000.0
> >> Random Write Working Set(GB) 1000.0
> >> Sequential Read Size(KB) 64KB
> >> Sequential Write Size(KB) 64KB
> >> Random Read Size(KB) 8KB
> >> Random Write Size(KB) 8KB
> >
> >So that's 85% reads and 15% writes, first part:
> >
> >rw=randrw
> >rwmixread=85
> >
> >and then you have 50/85 reads random and 35/85 reads sequential. That's
> >roughly 59% reads random. On the writes, you have 10/15 random and 5/15
> >sequential. That's roughly 67% writes random:
> >
> >percentage_random=59,67
> >
> >The latter I just added support for, before it only support a single
> >setting for reads and writes.
> >
> >Fio does not support splitting block sizes on a random/sequential basis.
> >You will have to improvise there.
> >
> >-- 
> >Jens Axboe
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe fio" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Hi Jens
> 
> This is neto from Brazil
> 
> How are you?
> 
> Thank you very much.
> 
> So basically the option right now is to use either 8KB or 64KB right?
> 
> Something like:
> 
> [workload]
> bs=8k
> ioengine=libaio
> iodepth=2
> numjobs=64
> direct=1
> runtime=2400
> size=2000g
> filename=\\.\PhysicalDrive9
> filename=\\.\PhysicalDrive10
> rw=randrw
> rwmixread=85
> percentage_random=59,67
> 
> thread
> unified_rw_reporting=1
> group_reporting=1
> 
> 
> Would be nice to have something like:
> 
> block_mixed=8192,65536 (random, sequential)

That would certainly easily be feasible. But since that would override
any other blocksize setting, might be cleaner to just have a boolean
saying whether to interpret these fields as "read,write" or
"sequential,random" instead.

BTW, if you use filename= twice like you do above, only the last one
will be effective.

-- 
Jens Axboe


  reply	other threads:[~2013-07-25 18:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CE142CC7.127F5%Antonio.Jose.Rodrigues.Neto@netapp.com>
2013-07-23 16:52 ` Helping to model this workload Neto, Antonio Jose Rodrigues
2013-07-25 16:45   ` Jens Axboe
2013-07-25 16:52     ` Neto, Antonio Jose Rodrigues
2013-07-25 18:27       ` Jens Axboe [this message]
2013-07-25 18:31         ` Neto, Antonio Jose Rodrigues
2013-07-25 18:42           ` Jens Axboe
2013-07-25 18:59             ` Neto, Antonio Jose Rodrigues
2013-07-25 19:02               ` Jens Axboe
2013-07-25 19:02               ` Neto, Antonio Jose Rodrigues
2013-07-25 19:03                 ` Jens Axboe
2013-07-25 19:07                   ` Neto, Antonio Jose Rodrigues
2013-07-25 19:11                     ` Jens Axboe
2013-07-25 19:50                       ` Neto, Antonio Jose Rodrigues
2013-07-26 14:22                         ` Neto, Antonio Jose Rodrigues
2013-07-26 14:24                           ` Jens Axboe
2013-07-26 14:28                             ` Neto, Antonio Jose Rodrigues
2013-07-26 14:34                               ` Jens Axboe
2013-07-26 14:35                                 ` Neto, Antonio Jose Rodrigues
2013-07-26 14:39                                   ` Neto, Antonio Jose Rodrigues

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=20130725182734.GH29296@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Antonio.Jose.Rodrigues.Neto@netapp.com \
    --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