Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Suresh Dhanarajan <sureshdrajan@gmail.com>
Cc: fio@vger.kernel.org
Subject: Re: Running fio with offset Increment option
Date: Sat, 14 Apr 2012 17:29:45 +0200	[thread overview]
Message-ID: <4F8997E9.6090206@kernel.dk> (raw)
In-Reply-To: <4F899663.8050406@kernel.dk>

On 2012-04-14 17:23, Jens Axboe wrote:
> On 2012-04-14 01:48, Suresh Dhanarajan wrote:
>> Hi,
>>
>> I wanted to use the "offset increment option" and  "numjobs" so that i
>> can split the work load between ten jobs and reduce the run time.
>> But what i am seeing is that the offset counter is not getting reset
>> when the first job in the jobfile is completed.(is it that the offset
>> is global for the job file and not for the Jobs inside the jobfile?)
>> So  my read starts from the last offset set by the writes.
>>
>> here is my job file,
>>
>> [global]
>> bs=64k
>> direct=1
>> numjobs=10
>> size=1m
>> group_reporting
>>
>> [write-phase]
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=write
>> write_iolog=verfywrite2
>>
>> [read-phase]
>> stonewall
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=read
>> write_iolog=verfyread2
>>
>> I tried using the offset=0 option in the read phase job but now every
>> time the read happens from zeroth offsite.
>> Now the offset increment option is not getting honored.
>>
>> [write-phase]
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=write
>> write_iolog=verfywrite2
>>
>> [read-phase]
>> stonewall
>> offset=0
>> offset_increment=1m
>> filename=/dev/sdb
>> rw=read
>> write_iolog=verfyread2
>>
>> I tried the same case with verify option.
>> the behavior is same.
>>
>> Is there any way that i can reset the offset counters once the job is completed?
> 
> Right now there isn't, but it does make sense to reset the counter
> across stonewalls. At the moment, it'll just increment for each job.
> Internally, fio sets up all the jobs, even across stonewalls, when it
> starts up. It just starts some of them later on, depending on those
> parameters. It does seem most useful to have it reset across a hard
> barrier though, I can definitely change it to do that.
> 
> Let me brew up a patch later today that you can test.

Had a few minutes now, didn't expect that. Can you try this? Do a make
clean first.

diff --git a/filesetup.c b/filesetup.c
index 166ace8..bad5bed 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -714,7 +714,7 @@ int setup_files(struct thread_data *td)
 	need_extend = 0;
 	for_each_file(td, f, i) {
 		f->file_offset = td->o.start_offset +
-			(td->thread_number - 1) * td->o.offset_increment;
+			(td->group_thread_number - 1) * td->o.offset_increment;
 
 		if (!td->o.file_size_low) {
 			/*
diff --git a/fio.h b/fio.h
index 95d9d77..05a5572 100644
--- a/fio.h
+++ b/fio.h
@@ -67,6 +67,7 @@ struct thread_data {
 	char verror[FIO_VERROR_SIZE];
 	pthread_t thread;
 	unsigned int thread_number;
+	unsigned int group_thread_number;
 	unsigned int groupid;
 	struct thread_stat ts;
 
diff --git a/init.c b/init.c
index 7422628..46571ee 100644
--- a/init.c
+++ b/init.c
@@ -35,6 +35,7 @@ static int dump_cmdline;
 static int def_timeout;
 
 static struct thread_data def_thread;
+static int group_thread_number;
 struct thread_data *threads = NULL;
 
 int exitall_on_terminate = 0;
@@ -829,8 +830,10 @@ static int add_job(struct thread_data *td, const char *jobname, int job_add_num,
 	if ((td->o.stonewall || td->o.new_group) && prev_group_jobs) {
 		prev_group_jobs = 0;
 		groupid++;
+		group_thread_number = 0;
 	}
 
+	td->group_thread_number = ++group_thread_number;
 	td->groupid = groupid;
 	prev_group_jobs++;
 

-- 
Jens Axboe


  reply	other threads:[~2012-04-14 15:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 23:48 Running fio with offset Increment option Suresh Dhanarajan
2012-04-14 15:23 ` Jens Axboe
2012-04-14 15:29   ` Jens Axboe [this message]
2012-04-16 23:15     ` Suresh Dhanarajan
2012-04-17  6:30       ` Jens Axboe
2012-04-18 21:37         ` Suresh Dhanarajan
2012-04-19  5:47           ` Jens Axboe
2012-04-19 19:32             ` Suresh Dhanarajan
2012-04-20  6:27               ` Jens Axboe
2012-04-28 19:09                 ` Suresh Dhanarajan
2012-05-02 12:12                   ` Jens Axboe

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=4F8997E9.6090206@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=fio@vger.kernel.org \
    --cc=sureshdrajan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox