On Mon, Mar 04 2013, Gavin Martin wrote: > On 4 March 2013 14:27, Jens Axboe <axboe@xxxxxxxxx> wrote: > > On Mon, Mar 04 2013, Gavin Martin wrote: > >> Hi, > >> > >> I'm trying to setup a job file that tests interleaved data, so in > >> theory writing 256K blocks with a gap of 256K in between, the end > >> results is that I would like to write extra data into the gaps and > >> make sure it is not corrupting neighbouring areas. > >> > >> But I'm having a problem with the first part. > >> > >> Here is the jobfile:- > >> > >> [global] > >> ioengine=libaio > >> direct=1 > >> filename=/dev/sdb > >> verify=meta > >> verify_backlog=1 > >> verify_dump=1 > >> verify_fatal=1 > >> stonewall > >> > >> [Job 2] > >> name=SeqWrite256K > >> description=Sequential Write with 1M Bands (256K) > >> rw=write:1M > >> bs=256K > >> do_verify=0 > >> verify_pattern=0x33333333 > >> size=1G > >> > >> [Job 4] > >> name=SeqVerify256K > >> description=Sequential Read/Verify from Sequential Write (256K) > >> rw=read:1M > >> bs=256K > >> do_verify=1 > >> verify_pattern=0x33333333 > >> size=1G > >> > >> There seems to be a bug (or maybe by design) when using the 'size=' > >> variable. It seems to count the gaps (1M) within the size of 1G, but > >> only on the write, the reads seems to report the IO transferred as 1G > >> > >> Here is the status of the runs:- > >> > >> Run status group 0 (all jobs): > >> WRITE: io=209920KB, aggrb=34039KB/s, minb=34039KB/s, maxb=34039KB/s, > >> mint=6167msec, maxt=6167msec > >> > >> Run status group 1 (all jobs): > >> READ: io=1025.0MB, aggrb=36759KB/s, minb=36759KB/s, maxb=36759KB/s, > >> mint=28553msec, maxt=28553msec > >> > >> And you can see the Write IO is a lot lower than the Read IO, even > >> though I have asked it to cover the same disk space. > >> > >> It could be that this is by design and it is my jobfile that is not > >> setup correctly, has anybody tried something like this before? > > > > They should behave identically - if they don't, then that is a bug. I > > will take a look at this tomorrow. > > > > -- > > Jens Axboe > > > Thanks Jens, > > I'm not sure if interleaved is the right term, I suppose could also be > called testing bands? > > I've just repeated using size=1% in case it was an issue with stating > a GB size, but it is still the same. > > I was also using fio-2.0.14 so have just grabbed the latest from Git > (fio-2.0.14-23-g9c63) and it exhibits the same issue. Does this work? diff --git a/libfio.c b/libfio.c index ac629dc..62a0c0b 100644 --- a/libfio.c +++ b/libfio.c @@ -81,12 +81,7 @@ static void reset_io_counters(struct thread_data *td) td->last_was_sync = 0; td->rwmix_issues = 0; - - /* - * reset file done count if we are to start over - */ - if (td->o.time_based || td->o.loops || td->o.do_verify) - td->nr_done_files = 0; + td->nr_done_files = 0; } void clear_io_state(struct thread_data *td) -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
