All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sitsofe Wheeler <sitsofe@gmail.com>
To: shashank chaurasia <shashankch9009@gmail.com>
Cc: fio <fio@vger.kernel.org>
Subject: Re: Query regarding [bsrange upper limit]
Date: Sun, 17 Jun 2018 07:49:00 +0100	[thread overview]
Message-ID: <CALjAwxgeO-o-hrF9+Gyre9T6eS+G7-o4EcNoWtuDHb_3-5spXQ@mail.gmail.com> (raw)
In-Reply-To: <CAD9xLVT+peBDZ9Sanp3pJ6+wue0C5phNPAZLjQVd1rGa9SLyMA@mail.gmail.com>

Hi,

On 17 June 2018 at 01:57, shashank chaurasia <shashankch9009@gmail.com> wrote:
> what is the bsrange upper limit that can be handled by fio properly?
>
> I sometimes see "invalid argument error" when I use
> bsrange=1k-32M

This is going to be down to the environment you're running (I shall
assume Linux for the rest of this email), the hardware you are using,
the ioengine you choose and the options you passed. If you are using
direct I/O (I can't tell because you didn't include the whole job
file/command line you using) then you cannot use a block size smaller
than the device's minimum sector size (for some devices that may be
4kbytes). Additionally there's a maximum transfer size of the "disk"
(/sys/block/<disk>/queue/max_sectors_kb) and there's the maximum size
the kernel will use (/sys/block/sda/queue/max_sectors_kb ). Further,
if you are choosing to transfer giant size blocks what's happening is
you typically forcing the kernel to split the block up into little
pieces for you (ideally the optimal_io_size which is generally much
smaller than the maximum). If you aren't able to submit I/O
asynchronously this can be a benefit (because you then get depth
parallelism) but if you can, sending such large I/Os just pushing
overhead into the kernel.

Another problem area can be down to unrealistically high option values
when everything is running together. For example, if you choose a high
iodepth, direct I/O, an asynchronous I/O engine, giant blocks and tons
of jobs your kernel may simply not have the resources to keep that
number of resultant hardware I/Os in flight.

-- 
Sitsofe | http://sucs.org/~sits/

           reply	other threads:[~2018-06-17  6:49 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CAD9xLVT+peBDZ9Sanp3pJ6+wue0C5phNPAZLjQVd1rGa9SLyMA@mail.gmail.com>]

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=CALjAwxgeO-o-hrF9+Gyre9T6eS+G7-o4EcNoWtuDHb_3-5spXQ@mail.gmail.com \
    --to=sitsofe@gmail.com \
    --cc=fio@vger.kernel.org \
    --cc=shashankch9009@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.