From: Jens Axboe <axboe@kernel.dk>
To: Nikolaus Jeremic <jeremic@informatik.uni-rostock.de>,
fio@vger.kernel.org
Subject: Re: Writing an amount of data less than capacity at random to offsets from whole address range
Date: Mon, 14 Apr 2014 14:11:03 -0600 [thread overview]
Message-ID: <534C40D7.3060406@kernel.dk> (raw)
In-Reply-To: <534BD74E.1080205@informatik.uni-rostock.de>
[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]
On 04/14/2014 06:40 AM, Nikolaus Jeremic wrote:
> Hello,
>
> how can I nudge fio to write a certain amount of data (less than
> capacity of block device) to randomly generated offsets covering the
> whole address space of a block device (e.g. MD RAID device)?
>
> Using the size parameter yields offsets from 0 to size (thus, not
> covering the whole address range). Using a time based job leads to the
> desired result, but I would like two write a defined amount of data. I
> have already tried this with fio 2.0.14, 2.1.6.1, 2.1.17, and 2.1.18
> without success. I am using Gentoo Linux with kernel 3.13.6 and libaio
> 0.3.109. The job description looks as follows:
Fio doesn't currently support that. Can you try the attached? It adds an
option to separately define an io limit, io_limit. If io_limit is not
set, size= behaves as it did before: if you don't give a size, size is
defined by the files added. With this patch, if you do
filename=/dev/md9
size=40g
fio would read 40g between 0..40G
If you do:
filename=/dev/md9
fio would access the entire device.
If you do:
filename=/dev/md9
io_limit=10g
fio would access the entire device, quit when 10G of IO was done. Etc.
--
Jens Axboe
[-- Attachment #2: fio-io-limit.patch --]
[-- Type: text/x-patch, Size: 4328 bytes --]
diff --git a/backend.c b/backend.c
index 62bca29194ed..47c4d32e8862 100644
--- a/backend.c
+++ b/backend.c
@@ -641,7 +641,7 @@ static unsigned int exceeds_number_ios(struct thread_data *td)
static int io_bytes_exceeded(struct thread_data *td)
{
- unsigned long long bytes;
+ unsigned long long bytes, limit;
if (td_rw(td))
bytes = td->this_io_bytes[DDIR_READ] + td->this_io_bytes[DDIR_WRITE];
@@ -652,7 +652,12 @@ static int io_bytes_exceeded(struct thread_data *td)
else
bytes = td->this_io_bytes[DDIR_TRIM];
- return bytes >= td->o.size || exceeds_number_ios(td);
+ if (td->o.io_limit)
+ limit = td->o.io_limit;
+ else
+ limit = td->o.size;
+
+ return bytes >= limit || exceeds_number_ios(td);
}
/*
@@ -1137,6 +1142,8 @@ static int switch_ioscheduler(struct thread_data *td)
static int keep_running(struct thread_data *td)
{
+ unsigned long long limit;
+
if (td->done)
return 0;
if (td->o.time_based)
@@ -1148,14 +1155,19 @@ static int keep_running(struct thread_data *td)
if (exceeds_number_ios(td))
return 0;
- if (td->o.size != -1ULL && ddir_rw_sum(td->io_bytes) < td->o.size) {
+ if (td->o.io_limit)
+ limit = td->o.io_limit;
+ else
+ limit = td->o.size;
+
+ if (limit != -1ULL && ddir_rw_sum(td->io_bytes) < limit) {
uint64_t diff;
/*
* If the difference is less than the minimum IO size, we
* are done.
*/
- diff = td->o.size - ddir_rw_sum(td->io_bytes);
+ diff = limit - ddir_rw_sum(td->io_bytes);
if (diff < td_max_bs(td))
return 0;
diff --git a/cconv.c b/cconv.c
index 5b9c3be2590c..a87f431c8c92 100644
--- a/cconv.c
+++ b/cconv.c
@@ -77,6 +77,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
o->iodepth_batch = le32_to_cpu(top->iodepth_batch);
o->iodepth_batch_complete = le32_to_cpu(top->iodepth_batch_complete);
o->size = le64_to_cpu(top->size);
+ o->io_limit = le64_to_cpu(top->io_limit);
o->size_percent = le32_to_cpu(top->size_percent);
o->fill_device = le32_to_cpu(top->fill_device);
o->file_append = le32_to_cpu(top->file_append);
@@ -425,6 +426,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
memcpy(top->buffer_pattern, o->buffer_pattern, MAX_PATTERN_SIZE);
top->size = __cpu_to_le64(o->size);
+ top->io_limit = __cpu_to_le64(o->io_limit);
top->verify_backlog = __cpu_to_le64(o->verify_backlog);
top->start_delay = __cpu_to_le64(o->start_delay);
top->start_delay_high = __cpu_to_le64(o->start_delay_high);
diff --git a/filesetup.c b/filesetup.c
index 490f0fc2101b..b614dbacabaa 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -939,8 +939,12 @@ int setup_files(struct thread_data *td)
* iolog already set the total io size, if we read back
* stored entries.
*/
- if (!o->read_iolog_file)
- td->total_io_size = o->size * o->loops;
+ if (!o->read_iolog_file) {
+ if (o->io_limit)
+ td->total_io_size = o->io_limit * o->loops;
+ else
+ td->total_io_size = o->size * o->loops;
+ }
done:
if (o->create_only)
diff --git a/options.c b/options.c
index 50af7b499f4b..163c5fc92985 100644
--- a/options.c
+++ b/options.c
@@ -1595,6 +1595,15 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
.group = FIO_OPT_G_INVALID,
},
{
+ .name = "io_limit",
+ .lname = "IO Limit",
+ .type = FIO_OPT_STR_VAL,
+ .off1 = td_var_offset(io_limit),
+ .interval = 1024 * 1024,
+ .category = FIO_OPT_C_IO,
+ .group = FIO_OPT_G_INVALID,
+ },
+ {
.name = "fill_device",
.lname = "Fill device",
.alias = "fill_fs",
diff --git a/server.h b/server.h
index 2958e7306c3e..4f09f2848b93 100644
--- a/server.h
+++ b/server.h
@@ -38,7 +38,7 @@ struct fio_net_cmd_reply {
};
enum {
- FIO_SERVER_VER = 33,
+ FIO_SERVER_VER = 34,
FIO_SERVER_MAX_FRAGMENT_PDU = 1024,
FIO_SERVER_MAX_CMD_MB = 2048,
diff --git a/thread_options.h b/thread_options.h
index 46421205cdf9..41b6e54e7372 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -52,6 +52,7 @@ struct thread_options {
unsigned int iodepth_batch_complete;
unsigned long long size;
+ unsigned long long io_limit;
unsigned int size_percent;
unsigned int fill_device;
unsigned int file_append;
@@ -280,6 +281,7 @@ struct thread_options_pack {
uint32_t iodepth_batch_complete;
uint64_t size;
+ uint64_t io_limit;
uint32_t size_percent;
uint32_t fill_device;
uint32_t file_append;
next prev parent reply other threads:[~2014-04-14 20:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 12:40 Writing an amount of data less than capacity at random to offsets from whole address range Nikolaus Jeremic
2014-04-14 20:11 ` Jens Axboe [this message]
2014-04-28 17:15 ` Nikolaus Jeremic
2014-04-29 2:03 ` 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=534C40D7.3060406@kernel.dk \
--to=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
--cc=jeremic@informatik.uni-rostock.de \
/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.