Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Michal Šmucr" <msmucr@gmail.com>
Cc: Alan Hagge <Alan.Hagge@warnerbros.com>, fio@vger.kernel.org
Subject: Re: How to re-use default sequential filenames?
Date: Fri, 5 Apr 2013 10:40:56 +0200	[thread overview]
Message-ID: <20130405084056.GM9683@kernel.dk> (raw)
In-Reply-To: <CAHBo9gmJHgZAjQ=rjeNpzrV7boLS6+2VcxtZRnkad7y_hwp=Dw@mail.gmail.com>

On Fri, Apr 05 2013, Michal Šmucr wrote:
> Hello to all,
> this is actually great thread. I discovered wonderful fio before two
> days during seeking for tool, which allows me to simulate typical
> workload with DPX files playback and recording (one file per frame).
> I'm playing with it today and slowly getting into options. By
> coincidence, i subscribed to this list to ask almost same question as
> Alan and found this first thread.. :-)
> Reusing of generated frames (file sequences) between write and read
> jobs is also important for me and is exactly thing, what i thought
> about. I will try to test patch by Jens.
> 
> One small thing, sorry for slight derail of thread topic, which come
> to my mind was option for kind of automatic set of blocksize during
> read to match length of each pre-generated file within sequence, which
> fio got from directory using opendir directive. Idea behind this come
> from common behaviour of VFX applications, which issue read io for
> whole frame size. So application use stat() output to get actual file
> size before reading of each frame. If I have same filesize per frame
> it is easy to adjust blocksize before benchmark, but if i want to test
> read performance of sequence with compressed frames or simulate
> mixture of different resolutions, this will be handy.

It would not be a problem making the block size decision probed or
dynamic. But it's not clear to me from the above what you would base it
on. The file size? Or st_blksize?

> Thank you and especially Jens for creation of fio (first day with it
> is mindblowing :)

You're welcome, glad you like it :-). Fio grows with great suggestions
from people actually using it, which this thread is a good example of.

-- 
Jens Axboe


  reply	other threads:[~2013-04-05  8:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-04 16:28 How to re-use default sequential filenames? Alan Hagge
2013-04-04 18:19 ` Jens Axboe
2013-04-04 18:41   ` Jens Axboe
2013-04-04 23:59     ` Michal Šmucr
2013-04-05  8:40       ` Jens Axboe [this message]
2013-04-05 19:24         ` Michal Šmucr
2013-04-05 19:31           ` Jens Axboe
2013-04-05  8:39     ` Jens Axboe
2013-04-07 23:28       ` Michal Šmucr
2013-04-08 11:17         ` Jens Axboe
2013-04-10 17:46           ` Alan Hagge
2013-04-11 11:18             ` Jens Axboe
2013-04-04 18:33 ` Matt Hayward
2013-04-04 19:02   ` Carl Zwanzig

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=20130405084056.GM9683@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Alan.Hagge@warnerbros.com \
    --cc=fio@vger.kernel.org \
    --cc=msmucr@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox