From: Jens Axboe <axboe@kernel.dk>
To: Grant Grundler <grundler@chromium.org>
Cc: Wallence Lu <wallencelu@gmail.com>, FIO_list <fio@vger.kernel.org>
Subject: Re: A bug in combining fsrange and verify
Date: Mon, 27 Jan 2014 16:31:16 -0700 [thread overview]
Message-ID: <20140127233116.GO2782@kernel.dk> (raw)
In-Reply-To: <CANEJEGspxdmAAhRCS7hiQeeFAOmSg9+ZwnZ_wcROji-9zE9tAg@mail.gmail.com>
On Mon, Jan 27 2014, Grant Grundler wrote:
> On Mon, Jan 27, 2014 at 3:03 PM, Jens Axboe <axboe@kernel.dk> wrote:
> > On Mon, Jan 27 2014, Jens Axboe wrote:
> >> On Mon, Jan 27 2014, Wallence Lu wrote:
> >> > Recreated with fio 2.0.11-35-g8428, the version was checked out from
> >> > https://github.com/axboe/fio.
> >>
> >> 2.1.4 is the latest, but I don't think that would change anything for
> >> you.
> >>
> >> > I read a little bit of the source code, it seems to me the randwrite
> >> > option gets the LBA without specifying the IO size. With that said,
> >> > for a bsrange option, it is likely one random IO can step onto another
> >> > IO if they happen to be adjacent. For example, request A has LBA
> >> > of 1024 and size 8K, request B has LBA 1016 and size 16K. Without
> >> > checking the request size, request B can overwrite content of request
> >> > A.
> >> >
> >> > Is that the right interpretation? Do I miss something? Thanks.
> >>
> >> Fio is supposed to handle that, the job file should work. I'll take a
> >> look at it.
> >
> > Works for me with the 2.1.4 release. It's actually broken in current
> > -git, due to the numberio patches..
>
> You mean all of the "verify_only" support patches or specifically this patch:
>
> commit da0a7bd224bb9331f27bb4b20394dd5c8fa3acb0
> Author: Juan Casse <jcasse@chromium.org>
> Date: Tue Sep 17 14:06:12 2013 -0700
>
> Adds check for numberio during verify phase.
>
> I can take a look at this tomorrow... let me see if I have the job
> file in another email.
It looks like it's actually catching the issue, when I take a closer
look. I'm afraid there might be overlapping ranges for bsrange=. You can
use the job file that was posted earlier in this thread. I reproduced
with that one, just changing the min bs to be 4k instead (to avoid btrfs
slowness...).
--
Jens Axboe
next prev parent reply other threads:[~2014-01-27 23:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-25 2:07 A bug in combining fsrange and verify Wallence Lu
2014-01-27 19:22 ` Jens Axboe
2014-01-27 20:42 ` Wallence Lu
2014-01-27 22:46 ` Jens Axboe
2014-01-27 23:03 ` Jens Axboe
2014-01-27 23:16 ` Grant Grundler
2014-01-27 23:31 ` Jens Axboe [this message]
2014-01-28 0:00 ` Grant Grundler
2014-01-28 17:26 ` Jens Axboe
2014-02-03 22:05 ` Grant Grundler
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=20140127233116.GO2782@kernel.dk \
--to=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
--cc=grundler@chromium.org \
--cc=wallencelu@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.