Flexible I/O Tester development
 help / color / mirror / Atom feed
* Generating almost-sequential traffic
@ 2013-06-26 22:31 Carl Zwanzig
  2013-06-27  9:01 ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Carl Zwanzig @ 2013-06-26 22:31 UTC (permalink / raw)
  To: fio@vger.kernel.org

Hi,

I need to test some devices with "almost-sequential" data traffic. This would have anywhere from 10 to 50 I/Os in order then either drop one from the sequence "1 2 3 (no 4) 5 6" or transpose two adjacent ones "1 2 (4 3) 5 6". This could be done with an iolog, but that seems both wasteful (huge files, 131k lines/MB) and slow (for reading and processing the files). To properly test, I need to move something like 3-4 Tb in 8k blocks.

It's also inelegant :). 

It looks like a drop sequence can be done with something like:
	blocksize=64k
	rw=write:8k
but I'm at a loss for how to do transposition.  Could be a hack into the get-next-block code in io_u.c, but I don't see how to actually implement that.

Any ideas (or is an iolog the best way)?

Thanks,

z!
Carl Zwanzig


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Generating almost-sequential traffic
  2013-06-26 22:31 Generating almost-sequential traffic Carl Zwanzig
@ 2013-06-27  9:01 ` Jens Axboe
  2013-06-27 17:41   ` Carl Zwanzig
  0 siblings, 1 reply; 4+ messages in thread
From: Jens Axboe @ 2013-06-27  9:01 UTC (permalink / raw)
  To: Carl Zwanzig; +Cc: fio@vger.kernel.org

On Wed, Jun 26 2013, Carl Zwanzig wrote:
> Hi,
> 
> I need to test some devices with "almost-sequential" data traffic. This would have anywhere from 10 to 50 I/Os in order then either drop one from the sequence "1 2 3 (no 4) 5 6" or transpose two adjacent ones "1 2 (4 3) 5 6". This could be done with an iolog, but that seems both wasteful (huge files, 131k lines/MB) and slow (for reading and processing the files). To properly test, I need to move something like 3-4 Tb in 8k blocks.
> 
> It's also inelegant :). 
> 
> It looks like a drop sequence can be done with something like:
> 	blocksize=64k
> 	rw=write:8k
> but I'm at a loss for how to do transposition.  Could be a hack into the get-next-block code in io_u.c, but I don't see how to actually implement that.
> 
> Any ideas (or is an iolog the best way)?

See percentage_random in the man page (or --cmdhelp=percentage_random)

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: Generating almost-sequential traffic
  2013-06-27  9:01 ` Jens Axboe
@ 2013-06-27 17:41   ` Carl Zwanzig
  2013-06-27 19:28     ` Jens Axboe
  0 siblings, 1 reply; 4+ messages in thread
From: Carl Zwanzig @ 2013-06-27 17:41 UTC (permalink / raw)
  To: Jens Axboe; +Cc: fio@vger.kernel.org

> From: Jens Axboe [mailto:axboe@kernel.dk]
> Sent: Thursday, June 27, 2013 2:01 AM

> See percentage_random in the man page (or --cmdhelp=percentage_random)

In the tests I'm running, the sequence has to continue essentially uninterrupted with the occasional drop/transposition, but it can't contain LBAs that are wildly off. So '1 2 3 (4) 5 6' or '1 2 3 (5 4) 6' are good, '1 2 3 9999 4 5 6' is not. They trigger different specific behaviors in some hard drives.

Is there a good place in the code to insert this sort or thing?

z!



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Generating almost-sequential traffic
  2013-06-27 17:41   ` Carl Zwanzig
@ 2013-06-27 19:28     ` Jens Axboe
  0 siblings, 0 replies; 4+ messages in thread
From: Jens Axboe @ 2013-06-27 19:28 UTC (permalink / raw)
  To: Carl Zwanzig; +Cc: fio@vger.kernel.org

On Thu, Jun 27 2013, Carl Zwanzig wrote:
> > From: Jens Axboe [mailto:axboe@kernel.dk]
> > Sent: Thursday, June 27, 2013 2:01 AM
> 
> > See percentage_random in the man page (or --cmdhelp=percentage_random)
> 
> In the tests I'm running, the sequence has to continue essentially
> uninterrupted with the occasional drop/transposition, but it can't
> contain LBAs that are wildly off. So '1 2 3 (4) 5 6' or '1 2 3 (5 4)
> 6' are good, '1 2 3 9999 4 5 6' is not. They trigger different
> specific behaviors in some hard drives.
> 
> Is there a good place in the code to insert this sort or thing?

I would look at the profile support in fio. That allows you to hook into
io_u.c:get_next_offset(), which is where fio decides what the next
offset should be. If a profile defines ops->fill_io_u(), then that is
called instead. That gives you absolute control of the IO pattern,
without having to modify core fio code.

-- 
Jens Axboe



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-06-27 19:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-26 22:31 Generating almost-sequential traffic Carl Zwanzig
2013-06-27  9:01 ` Jens Axboe
2013-06-27 17:41   ` Carl Zwanzig
2013-06-27 19:28     ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox