Re: offset broken for randwrite?

From: Jens Axboe <jens.axboe_at_oracle.com>
Date: Mon, 18 Feb 2008 14:16:19 +0100

On Tue, Feb 12 2008, Ryan Thomas wrote:
> It seems that the offset parameter cannot be used with randwrite testing.
>
> I was trying to test alignment issues with a libaio randwrite test described by the following command file:
>
> [global]
> bs=64k
> size=2G
> filesize=64G
> direct=1
> rw=randwrite:1
> ioengine=libaio
> iodepth=32
> write_bw_log
> fadvise_hint=0
>
> [xraid]
> numjobs=1
> write_iolog=xr.opt.log
> offset=131072
> filename=/dev/sdf
>
> When I got suspiciously high throughput I looked at the I/O log to find that the same blocks at the end of file were being written over and over again.
>
> fio version 2 iolog
> /dev/sdf add
> /dev/sdf open
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
> /dev/sdf write 68719411200 65536
>
> Since I am testing a block device, a workaround is to use a partition to align the I/O but I'd prefer to do it with just fio.
>
> Also note that having a working offset parameter is key to testing block devices without wiping out the partition table. For example, the standard randwrite test with no offset writes a block at the end of file and at the start of file and then goes through the test as is shown in this example:
>
> fio version 2 iolog
> /dev/sdf add
> /dev/sdf open
> /dev/sdf write 68718428160 655360
> /dev/sdf write 0 655360
> /dev/sdf write 655360 655360
> /dev/sdf write 1310720 655360
>
> This will wipe out the partition table. So it's absolutely necessary to be able to specify an offset parameter to protect the partition table. For gpt partition tables that have a mirror at the end of device, it's similarly necessary to be able protect the final partition table with a filesize option. Protecting the end of a block device seems to work today, protecting the start does not.

Sorry for the late response, I was on vacation last week. It is indeed
the offset screwing things up, mark_random_map() needs to take that into
account. Does this work?

diff --git a/io_u.c b/io_u.c
index 8f10bfd..c102d5f 100644
--- a/io_u.c
+++ b/io_u.c
@@ -44,7 +44,7 @@ static void mark_random_map(struct thread_data *td, struct io_u *io_u)
         unsigned int blocks;
         unsigned int nr_blocks;
 
- block = io_u->offset / (unsigned long long) min_bs;
+ block = (io_u->offset - f->file_offset) / (unsigned long long) min_bs;
         blocks = 0;
         nr_blocks = (io_u->buflen + min_bs - 1) / min_bs;
 

-- 
Jens Axboe
Received on Mon Feb 18 2008 - 14:16:19 CET

This archive was generated by hypermail 2.2.0 : Mon Feb 18 2008 - 14:30:02 CET