Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Vincent Fu <vincent.fu@samsung.com>
To: Nick Neumann <nick@pcpartpicker.com>,
	"fio@vger.kernel.org" <fio@vger.kernel.org>
Subject: RE: Odd (wrong?) behavior with :<nr> suffix on readwrite parameter
Date: Thu, 10 Feb 2022 22:52:29 +0000	[thread overview]
Message-ID: <65c1d4d55d0a41c1934d46b2c09dd9a6@samsung.com> (raw)
In-Reply-To: <CADqNVTrbc+gtK1PuLLZqaGTTeppXckTP-TFPaRT__iF63+f3Kg@mail.gmail.com>

> -----Original Message-----
> From: Nick Neumann [mailto:nick@pcpartpicker.com]
> Sent: Monday, February 7, 2022 6:15 PM
> To: fio@vger.kernel.org
> Subject: Odd (wrong?) behavior with :<nr> suffix on readwrite parameter
> 
> I was playing with this feature today. It seems like a nice feature as it will
> allow you to simulate a read or write of a somewhat fragmented file. From
> the docs, I can do something like
> --rw=randread:8
> and expect fio will do 8 I/Os "before getting a new offset". So when fio does
> its reads, they will occur at offset1, offset1+block_size,
> offset1+block_size*2, ... offset1+block_size*7, and then at a new
> random offset2, followed by offset2+block_size, offset2+block_size*2, etc...
> 
> What I'm seeing with this feature though is that using it causes the first offset
> chosen to always be 0, and it is used (plus multiples of block size) for the first
> 7 (nr-1) I/Os. For example, with this
> command:
> 
> sudo fio --ioengine=libaio --direct=1 --output-format=json+ --name=job
> --filename=/dev/nvme1n1 --size=128MB --rw=randread:8 --iodepth=1 --
> bs=4K --write_bw_log=fio_0 --log_offset=1
> 
> The bandwidth log entries are (fifth column is the offset):
> 
> 14, 288, 0, 4096, 0, 0
> 14, 36141, 0, 4096, 4096, 0
> 14, 34715, 0, 4096, 8192, 0
> 14, 34406, 0, 4096, 12288, 0
> 14, 34700, 0, 4096, 16384, 0
> 14, 27766, 0, 4096, 20480, 0
> 15, 34633, 0, 4096, 24576, 0
> 15, 20233, 0, 4096, 8093696, 0
> 15, 39409, 0, 4096, 8097792, 0
> 
> This seems odd, and kinda wrong - the first nr-1 ops do not happen from a
> random offset as specified by the randread/randwrite value, but instead
> from offset 0. When one does a random I/O operation without the :<nr>
> suffix, the first operation is from a random offset, not 0.
> 
> I'm happy to find and fix the behavior, but wanted to first make sure it isn't
> intentional or that I'm somehow misunderstanding it.

I tried running with randrepeat=0 and saw the same behavior you did. With the default randrepeat=1 fio will always use the same random number seed for IO offsets, but even with randrepeat=0, rw=randread:8 always started at offset 0.

I agree with your assessment that rw=randread:8 should start at a random offset.

Vincent

  reply	other threads:[~2022-02-10 22:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20220208010644uscas1p132e264f9a90c2e515846440393203738@uscas1p1.samsung.com>
2022-02-07 23:14 ` Odd (wrong?) behavior with :<nr> suffix on readwrite parameter Nick Neumann
2022-02-10 22:52   ` Vincent Fu [this message]
2022-02-10 23:08     ` Nick Neumann
2022-02-15 18:04       ` Nick Neumann

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=65c1d4d55d0a41c1934d46b2c09dd9a6@samsung.com \
    --to=vincent.fu@samsung.com \
    --cc=fio@vger.kernel.org \
    --cc=nick@pcpartpicker.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