From: Jens Axboe <jens.axboe@oracle.com>
To: Radha Ramachandran <radha@google.com>
Cc: fio@vger.kernel.org
Subject: Re: Issue running random reads with verify on a raw device
Date: Sat, 18 Apr 2009 19:53:09 +0200 [thread overview]
Message-ID: <20090418175308.GE4593@kernel.dk> (raw)
In-Reply-To: <66dfd3fe0904101557g99d6b63r5a24a84cfe01ffbf@mail.gmail.com>
On Fri, Apr 10 2009, Radha Ramachandran wrote:
> Hi,
> We have a test that runs the test on a raw device say of size 100GB
> > Sequential write of a pattern to the raw device with size=10GB (so even though the device is 100GB big we try to write only to the first 10GB)
> > Random read and verify of the pattern to the raw device with size=10GB, (with randommap, so we maintain the bitmap of previously visited blocks)
>
> This test almost always lands up trying to do the read beyond the
> 10GB. So I see this code in io_u.c:
>
> static int get_next_free_block(struct thread_data *td, struct fio_file *f,
> enum fio_ddir ddir, unsigned long long *b) {
> ...
> while ((*b) * min_bs < f->real_file_size) { ========= This
> code looks for an unvisited block within the real_file_size which in
> this case is 100GB, and will exceed 10GB in a lot of cases causing the
> verify to fail.
>
>
> So i fixed this by checking if the block is within the real_file_size
> and the io_size, so this wld work in cases where:
> 1. Actual file size < io_size
> 2. io_size < Actual file size
>
>
> diff -crB io_u.c io_u.c_fixed
> *** io_u.c Fri Apr 10 15:47:02 2009
> --- io_u.c_fixed Fri Apr 10 15:48:02 2009
> ***************
> *** 113,119 ****
>
> i = f->last_free_lookup;
> *b = (i * BLOCKS_PER_MAP);
> ! while ((*b) * min_bs < f->real_file_size) {
> if (f->file_map[i] != (unsigned int) -1) {
> *b += ffz(f->file_map[i]);
> if (*b > last_block(td, f, ddir))
> --- 113,120 ----
>
> i = f->last_free_lookup;
> *b = (i * BLOCKS_PER_MAP);
> ! while (((*b) * min_bs < f->real_file_size) &&
> ! ((*b) * min_bs < f->io_size)) {
> if (f->file_map[i] != (unsigned int) -1) {
> *b += ffz(f->file_map[i]);
> if (*b > last_block(td, f, ddir))
>
>
> Is there some case I missed?
Yeah I don't think this will work for using an offset within the file,
as it's legal for the offset to be larger than the io_size. If you can
check and add the offset check, I think it should be ok.
--
Jens Axboe
next prev parent reply other threads:[~2009-04-18 17:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-10 22:57 Issue running random reads with verify on a raw device Radha Ramachandran
2009-04-18 17:53 ` Jens Axboe [this message]
2009-04-21 23:31 ` Radha Ramachandran
2009-04-22 6:05 ` Jens Axboe
2009-04-22 6:21 ` Jens Axboe
2009-04-22 6:22 ` Radha Ramachandran
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=20090418175308.GE4593@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=fio@vger.kernel.org \
--cc=radha@google.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.