fio offset with ba

fio offset with ba

[Jeff Furlong]

Hi All,
I don't quite follow the logic in the calculate offset function.  The offset parameter recently allows a percentage.  Suppose we set it to 50% and want to block align the IO's starting at 50% of device capacity, then block aligned to 8KB.

# fio -version
fio-3.1-60-g71aa

# blockdev --getsize64 /dev/nvme1n1
3200631791616

# fio --name=test_job --ioengine=libaio --direct=1 --rw=read --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --runtime=1s --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k

# cat test_job_iops.1.log
0, 1, 0, 4096, 1600315895808
0, 1, 0, 4096, 1600315899904
0, 1, 0, 4096, 1600315904000
0, 1, 0, 4096, 1600315908096

So we can see the device has 3200631791616 bytes, 50% of which is 1600315895808 bytes, which happens to be 4KB aligned, but not 8KB aligned.  Even though we set the --ba=8k parameter, the offset LBA as logged in the iops.1.log shows 4KB alignment.  Does --ba work for all IO's or only random IO's?  If all, does get_start_offset() control the raw offset value?  I don't see why the min(ba, bs) is used in the calculation, but perhaps I am missing something.  Thanks.

Regards,
Jeff

Re: fio offset with ba

[Sitsofe Wheeler]

Hi,

On 20 October 2017 at 20:08, Jeff Furlong <jeff.furlong@wdc.com> wrote:
>
> I don't quite follow the logic in the calculate offset function.  The offset parameter recently allows a percentage.  Suppose we set it to 50% and want to block align the IO's starting at 50% of device capacity, then block aligned to 8KB.
>
> # fio -version
> fio-3.1-60-g71aa
>
> # blockdev --getsize64 /dev/nvme1n1
> 3200631791616
>
> # fio --name=test_job --ioengine=libaio --direct=1 --rw=read --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --runtime=1s --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k
>
> # cat test_job_iops.1.log
> 0, 1, 0, 4096, 1600315895808
> 0, 1, 0, 4096, 1600315899904
> 0, 1, 0, 4096, 1600315904000
> 0, 1, 0, 4096, 1600315908096
>
> So we can see the device has 3200631791616 bytes, 50% of which is 1600315895808 bytes, which happens to be 4KB aligned, but not 8KB aligned.  Even though we set the --ba=8k parameter, the offset LBA as logged in the iops.1.log shows

Hmm I see the same problem with this job:
fio --name=test_job --ioengine=null --rw=read --iodepth=1
--size=3200631791616 --bs=4k --number_ios=1 --offset=50% --ba=8k
--debug=io

[...]
io       15013 fill_io_u: io_u 0x236ad80:
off=1600315895808/len=4096/ddir=0io       15013 /test_job.0.0io
15013

I think your guess about only impacting random I/O is probably right because
fio --name=test_job --randrepeat=0 --ioengine=null --rw=randread
--iodepth=1 --size=3200631791616 --bs=4k --number_ios=1 --offset=50%
--ba=8k --debug=io

picks offsets that are 8k aligned.

> 4KB alignment.  Does --ba work for all IO's or only random IO's?  If all, does get_start_offset() control the raw offset value?  I don't see why the min(ba, bs) is used in the calculation, but perhaps I am missing something.  Thanks.

Where is min(ba, bs) done - do you mean the bits around
https://github.com/axboe/fio/commit/89978a6b26f81bdbd63228e2e2a86f604ee46c56#diff-4abbf037246dd2e450dc3f6a2ac77180R845?
I agree you probably want to take the maximum of all the block
alignments but what if one of the smaller ones is not a multiple of
the largest one?

Would you like to propose a patch?

-- 
Sitsofe | http://sucs.org/~sits/

RE: fio offset with ba

[Jeff Furlong]

Yes, the bits around line 845 show the min() being used.  It seems get_start_offset() is used for the first IO and subsequent IO's, making things difficult.  I believe the correct fix here would be to set the ba specific to the io type.  The ba parameter allows for read/write/trim alignments.  So if io_u->ddir==DDIR_READ then we could just align to o->ba[DDIR_READ].  But I don't see how we would access io_u at this point, we don't know of the potential io_u at this time?  It could be a mixed read/write/trim.

Lacking that, brute force would suggest:

		if (fio_option_is_set(o, ba)) {	
			align_bs = (unsigned long long) o->ba[DDIR_READ];
			if(o->ba[DDIR_READ] != o->ba[DDIR_WRITE])
				align_bs = (unsigned long long) o->ba[DDIR_READ] * (unsigned long long) o->ba[DDIR_WRITE];
			if(align_bs != (unsigned long long) o->ba[DDIR_TRIM])
				align_bs = align_bs * (unsigned long long) o->ba[DDIR_TRIM];

But I see another problem in that o->ba[DDIR_READ] is not set for sequential workloads.  In fixup_options() we have:

	if (!o->ba[DDIR_READ] || !td_random(td))
		o->ba[DDIR_READ] = o->min_bs[DDIR_READ];
	if (!o->ba[DDIR_WRITE] || !td_random(td))
		o->ba[DDIR_WRITE] = o->min_bs[DDIR_WRITE];
	if (!o->ba[DDIR_TRIM] || !td_random(td))
		o->ba[DDIR_TRIM] = o->min_bs[DDIR_TRIM];

I don't follow that code, other than if sequential, set ba to min_bs?  If we remove that code and use above change, we can get the starting LBA to be aligned to the ba in the case of 

fio --name=test_job --ioengine=libaio --direct=1 --rw=read --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --number_ios=8 --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k

# cat test_job_iops.1.log
0, 1, 0, 4096, 1600315899904

It seems to be a hack, so I didn't create a patch for it.  Would like to better understand what I'm missing before breaking something.

Thanks.

Regards,
Jeff


-----Original Message-----
From: Sitsofe Wheeler [mailto:sitsofe@gmail.com] 
Sent: Friday, October 20, 2017 2:01 PM
To: Jeff Furlong <jeff.furlong@wdc.com>
Cc: fio@vger.kernel.org
Subject: Re: fio offset with ba

Hi,

On 20 October 2017 at 20:08, Jeff Furlong <jeff.furlong@wdc.com> wrote:
>
> I don't quite follow the logic in the calculate offset function.  The offset parameter recently allows a percentage.  Suppose we set it to 50% and want to block align the IO's starting at 50% of device capacity, then block aligned to 8KB.
>
> # fio -version
> fio-3.1-60-g71aa
>
> # blockdev --getsize64 /dev/nvme1n1
> 3200631791616
>
> # fio --name=test_job --ioengine=libaio --direct=1 --rw=read 
> --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --runtime=1s 
> --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k
>
> # cat test_job_iops.1.log
> 0, 1, 0, 4096, 1600315895808
> 0, 1, 0, 4096, 1600315899904
> 0, 1, 0, 4096, 1600315904000
> 0, 1, 0, 4096, 1600315908096
>
> So we can see the device has 3200631791616 bytes, 50% of which is 
> 1600315895808 bytes, which happens to be 4KB aligned, but not 8KB 
> aligned.  Even though we set the --ba=8k parameter, the offset LBA as 
> logged in the iops.1.log shows

Hmm I see the same problem with this job:
fio --name=test_job --ioengine=null --rw=read --iodepth=1
--size=3200631791616 --bs=4k --number_ios=1 --offset=50% --ba=8k --debug=io

[...]
io       15013 fill_io_u: io_u 0x236ad80:
off=1600315895808/len=4096/ddir=0io       15013 /test_job.0.0io
15013

I think your guess about only impacting random I/O is probably right because fio --name=test_job --randrepeat=0 --ioengine=null --rw=randread
--iodepth=1 --size=3200631791616 --bs=4k --number_ios=1 --offset=50% --ba=8k --debug=io

picks offsets that are 8k aligned.

> 4KB alignment.  Does --ba work for all IO's or only random IO's?  If all, does get_start_offset() control the raw offset value?  I don't see why the min(ba, bs) is used in the calculation, but perhaps I am missing something.  Thanks.

Where is min(ba, bs) done - do you mean the bits around https://github.com/axboe/fio/commit/89978a6b26f81bdbd63228e2e2a86f604ee46c56#diff-4abbf037246dd2e450dc3f6a2ac77180R845?
I agree you probably want to take the maximum of all the block alignments but what if one of the smaller ones is not a multiple of the largest one?

Would you like to propose a patch?

--
Sitsofe | http://sucs.org/~sits/

Re: fio offset with ba

[Sitsofe Wheeler]

Hmm,

I see a few choices for trying to solve alignment of the offset and
forced alignment of sequential blocks:
* Introduce an "offset_align" option solely for aligning the "initial"
offset and stop trying to use blockalign in the offset. Document it
well to stop confusion with blockalign.
* Document blockalign as ONLY working for random I/O or
* Do blockalign for sequential I/O on a per I/O basis (potentially
creating gappy I/O). This is also the request from
https://github.com/axboe/fio/issues/341 . Technically this is has a
big overlap with zoned I/O and the existing "generated offset" used in
rw option but perhaps it's just different enough to be justified?

Thoughts?

On 21 October 2017 at 01:13, Jeff Furlong <jeff.furlong@wdc.com> wrote:
> Yes, the bits around line 845 show the min() being used.  It seems get_start_offset() is used for the first IO and subsequent IO's, making things difficult.  I believe the correct fix here would be to set the ba specific to the io type.  The ba parameter allows for read/write/trim alignments.  So if io_u->ddir==DDIR_READ then we could just align to o->ba[DDIR_READ].  But I don't see how we would access io_u at this point, we don't know of the potential io_u at this time?  It could be a mixed read/write/trim.
>
> Lacking that, brute force would suggest:
>
>                 if (fio_option_is_set(o, ba)) {
>                         align_bs = (unsigned long long) o->ba[DDIR_READ];
>                         if(o->ba[DDIR_READ] != o->ba[DDIR_WRITE])
>                                 align_bs = (unsigned long long) o->ba[DDIR_READ] * (unsigned long long) o->ba[DDIR_WRITE];
>                         if(align_bs != (unsigned long long) o->ba[DDIR_TRIM])
>                                 align_bs = align_bs * (unsigned long long) o->ba[DDIR_TRIM];
>
> But I see another problem in that o->ba[DDIR_READ] is not set for sequential workloads.  In fixup_options() we have:
>
>         if (!o->ba[DDIR_READ] || !td_random(td))
>                 o->ba[DDIR_READ] = o->min_bs[DDIR_READ];
>         if (!o->ba[DDIR_WRITE] || !td_random(td))
>                 o->ba[DDIR_WRITE] = o->min_bs[DDIR_WRITE];
>         if (!o->ba[DDIR_TRIM] || !td_random(td))
>                 o->ba[DDIR_TRIM] = o->min_bs[DDIR_TRIM];
>
> I don't follow that code, other than if sequential, set ba to min_bs?  If we remove that code and use above change, we can get the starting LBA to be aligned to the ba in the case of
>
> fio --name=test_job --ioengine=libaio --direct=1 --rw=read --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --number_ios=8 --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k
>
> # cat test_job_iops.1.log
> 0, 1, 0, 4096, 1600315899904
>
> It seems to be a hack, so I didn't create a patch for it.  Would like to better understand what I'm missing before breaking something.
>
> Thanks.
>
> Regards,
> Jeff
>
>
> -----Original Message-----
> From: Sitsofe Wheeler [mailto:sitsofe@gmail.com]
> Sent: Friday, October 20, 2017 2:01 PM
> To: Jeff Furlong <jeff.furlong@wdc.com>
> Cc: fio@vger.kernel.org
> Subject: Re: fio offset with ba
>
> Hi,
>
> On 20 October 2017 at 20:08, Jeff Furlong <jeff.furlong@wdc.com> wrote:
>>
>> I don't quite follow the logic in the calculate offset function.  The offset parameter recently allows a percentage.  Suppose we set it to 50% and want to block align the IO's starting at 50% of device capacity, then block aligned to 8KB.
>>
>> # fio -version
>> fio-3.1-60-g71aa
>>
>> # blockdev --getsize64 /dev/nvme1n1
>> 3200631791616
>>
>> # fio --name=test_job --ioengine=libaio --direct=1 --rw=read
>> --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --runtime=1s
>> --offset=50% --log_offset=1 --write_iops_log=test_job --ba=8k
>>
>> # cat test_job_iops.1.log
>> 0, 1, 0, 4096, 1600315895808
>> 0, 1, 0, 4096, 1600315899904
>> 0, 1, 0, 4096, 1600315904000
>> 0, 1, 0, 4096, 1600315908096
>>
>> So we can see the device has 3200631791616 bytes, 50% of which is
>> 1600315895808 bytes, which happens to be 4KB aligned, but not 8KB
>> aligned.  Even though we set the --ba=8k parameter, the offset LBA as
>> logged in the iops.1.log shows
>
> Hmm I see the same problem with this job:
> fio --name=test_job --ioengine=null --rw=read --iodepth=1
> --size=3200631791616 --bs=4k --number_ios=1 --offset=50% --ba=8k --debug=io
>
> [...]
> io       15013 fill_io_u: io_u 0x236ad80:
> off=1600315895808/len=4096/ddir=0io       15013 /test_job.0.0io
> 15013
>
> I think your guess about only impacting random I/O is probably right because fio --name=test_job --randrepeat=0 --ioengine=null --rw=randread
> --iodepth=1 --size=3200631791616 --bs=4k --number_ios=1 --offset=50% --ba=8k --debug=io
>
> picks offsets that are 8k aligned.
>
>> 4KB alignment.  Does --ba work for all IO's or only random IO's?  If all, does get_start_offset() control the raw offset value?  I don't see why the min(ba, bs) is used in the calculation, but perhaps I am missing something.  Thanks.
>
> Where is min(ba, bs) done - do you mean the bits around https://github.com/axboe/fio/commit/89978a6b26f81bdbd63228e2e2a86f604ee46c56#diff-4abbf037246dd2e450dc3f6a2ac77180R845?
> I agree you probably want to take the maximum of all the block alignments but what if one of the smaller ones is not a multiple of the largest one?
>
> Would you like to propose a patch?
>
> --
> Sitsofe | http://sucs.org/~sits/

-- 
Sitsofe | http://sucs.org/~sits/

RE: fio offset with ba

[Jeff Furlong]

>Hmm,
>
>I see a few choices for trying to solve alignment of the offset and forced alignment of sequential blocks:
>* Introduce an "offset_align" option solely for aligning the "initial"
>offset and stop trying to use blockalign in the offset. Document it well to stop confusion with blockalign.
>* Document blockalign as ONLY working for random I/O or
>* Do blockalign for sequential I/O on a per I/O basis (potentially creating gappy I/O). This is also the request from
>https://github.com/axboe/fio/issues/341 . Technically this is has a big overlap with zoned I/O and the existing "generated offset" used in rw >option but perhaps it's just different enough to be justified?
>
>Thoughts?

I tried the first approach.  Second approach seems set on random I/O already.  Third approach seems problematic with gappy I/O, unless you really want to skip some LBAs (possible, just not my intention on this workload).

# fio --name=test_job --ioengine=libaio --direct=1 --rw=read --iodepth=1 --size=100% --bs=4k --filename=/dev/nvme1n1 --number_ios=8 --offset=50% --log_offset=1 --write_iops_log=test_job --offset_align=8k

# cat test_job_iops.1.log 
0, 1, 0, 4096, 1600315899904
0, 1, 0, 4096, 1600315904000
0, 1, 0, 4096, 1600315908096
0, 1, 0, 4096, 1600315912192
0, 1, 0, 4096, 1600315916288
0, 1, 0, 4096, 1600315920384
0, 1, 0, 4096, 1600315924480
0, 1, 0, 4096, 1600315928576



diff --git a/HOWTO b/HOWTO
index 22a5849..c611fae 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1128,13 +1128,19 @@ I/O type
 .. option:: offset=int
 
 	Start I/O at the provided offset in the file, given as either a fixed size in
-	bytes or a percentage. If a percentage is given, the next ``blockalign``-ed
+	bytes or a percentage. If a percentage is given, the next ``bs`` ``blockalign``-ed
 	offset will be used. Data before the given offset will not be touched. This
 	effectively caps the file size at `real_size - offset`. Can be combined with
 	:option:`size` to constrain the start and end range of the I/O workload.
 	A percentage can be specified by a number between 1 and 100 followed by '%',
 	for example, ``offset=20%`` to specify 20%.
 
+.. option:: offset_align=int
+
+	If a precentage offset is given, the provided offset is ``blockalign``-ed to
+	the ``blocksize``. This value will align the initial I/O to a new alignment.
+	Applies to sequential workloads only.
+
 .. option:: offset_increment=int
 
 	If this is provided, then the real offset becomes `offset + offset_increment
diff --git a/cconv.c b/cconv.c
index f809fd5..dc3c4e6 100644
--- a/cconv.c
+++ b/cconv.c
@@ -105,6 +105,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
 	o->file_size_low = le64_to_cpu(top->file_size_low);
 	o->file_size_high = le64_to_cpu(top->file_size_high);
 	o->start_offset = le64_to_cpu(top->start_offset);
+	o->start_offset_align = le64_to_cpu(top->start_offset_align);
 	o->start_offset_percent = le32_to_cpu(top->start_offset_percent);
 
 	for (i = 0; i < DDIR_RWDIR_CNT; i++) {
@@ -548,6 +549,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
 	top->file_size_low = __cpu_to_le64(o->file_size_low);
 	top->file_size_high = __cpu_to_le64(o->file_size_high);
 	top->start_offset = __cpu_to_le64(o->start_offset);
+	top->start_offset_align = __cpu_to_le64(o->start_offset_align);
 	top->start_offset_percent = __cpu_to_le32(o->start_offset_percent);
 	top->trim_backlog = __cpu_to_le64(o->trim_backlog);
 	top->offset_increment = __cpu_to_le64(o->offset_increment);
diff --git a/filesetup.c b/filesetup.c
index 7a602d4..97535e7 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -869,10 +869,15 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
 
 	if (o->start_offset_percent > 0) {
 		/*
+		 * if offset_align is provided, set initial offset
+		 */
+		if (fio_option_is_set(o, start_offset_align)) {
+			align_bs = o->start_offset_align;
+		/*
 		 * if blockalign is provided, find the min across read, write,
 		 * and trim
 		 */
-		if (fio_option_is_set(o, ba)) {
+		} else if (fio_option_is_set(o, ba)) {
 			align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
 			align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);
 		} else {
diff --git a/fio.1 b/fio.1
index 7787ef2..098ca2e 100644
--- a/fio.1
+++ b/fio.1
@@ -913,13 +913,18 @@ should be associated with them.
 .TP
 .BI offset \fR=\fPint
 Start I/O at the provided offset in the file, given as either a fixed size in
-bytes or a percentage. If a percentage is given, the next \fBblockalign\fR\-ed
+bytes or a percentage. If a percentage is given, the next \fBbs\fR \fBblockalign\fR\-ed
 offset will be used. Data before the given offset will not be touched. This
 effectively caps the file size at `real_size \- offset'. Can be combined with
 \fBsize\fR to constrain the start and end range of the I/O workload.
 A percentage can be specified by a number between 1 and 100 followed by '%',
 for example, `offset=20%' to specify 20%.
 .TP
+.BI offset_align \fR=\fPint
+If a precentage offset is given, the provided offset is \fBblockalign\fR\-ed to
+the \fBblocksize\fR. This value will align the initial I/O to a new alignment.
+Applies to sequential workloads only.
+.TP
 .BI offset_increment \fR=\fPint
 If this is provided, then the real offset becomes `\fBoffset\fR + \fBoffset_increment\fR
 * thread_number', where the thread number is a counter that starts at 0 and
diff --git a/options.c b/options.c
index ddcc4e5..a7821d7 100644
--- a/options.c
+++ b/options.c
@@ -2019,6 +2019,17 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
 		.group	= FIO_OPT_G_INVALID,
 	},
 	{
+		.name	= "offset_align",
+		.lname	= "IO offset alignment",
+		.type	= FIO_OPT_STR_VAL,
+		.off1	= offsetof(struct thread_options, start_offset_align),
+		.help	= "Start IO from this offset alignment",
+		.def	= "0",
+		.interval = 1024 * 1024,
+		.category = FIO_OPT_C_IO,
+		.group	= FIO_OPT_G_INVALID,
+	},
+	{
 		.name	= "offset_increment",
 		.lname	= "IO offset increment",
 		.type	= FIO_OPT_STR_VAL,
diff --git a/thread_options.h b/thread_options.h
index 1813cdc..5a037bf 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -78,6 +78,7 @@ struct thread_options {
 	unsigned long long file_size_low;
 	unsigned long long file_size_high;
 	unsigned long long start_offset;
+	unsigned long long start_offset_align;
 
 	unsigned int bs[DDIR_RWDIR_CNT];
 	unsigned int ba[DDIR_RWDIR_CNT];
@@ -355,6 +356,7 @@ struct thread_options_pack {
 	uint64_t file_size_low;
 	uint64_t file_size_high;
 	uint64_t start_offset;
+	uint64_t start_offset_align;
 
 	uint32_t bs[DDIR_RWDIR_CNT];
 	uint32_t ba[DDIR_RWDIR_CNT];



Regards,
Jeff

Re: fio offset with ba

[Sitsofe Wheeler]

On 24 October 2017 at 00:56, Jeff Furlong <jeff.furlong@wdc.com> wrote:
>
> diff --git a/HOWTO b/HOWTO
> index 22a5849..c611fae 100644
> --- a/HOWTO
> +++ b/HOWTO
> @@ -1128,13 +1128,19 @@ I/O type
>  .. option:: offset=int
>
>         Start I/O at the provided offset in the file, given as either a fixed size in
> -       bytes or a percentage. If a percentage is given, the next ``blockalign``-ed
> +       bytes or a percentage. If a percentage is given, the next ``bs`` ``blockalign``-ed

I'd stop referencing blockalign here to avoid confusion and say something like:

When a percentage is given, the generated offset will be aligned up to
the minimum ``blocksize`` or to the value of ``offset_align``.

>         offset will be used. Data before the given offset will not be touched. This
>         effectively caps the file size at `real_size - offset`. Can be combined with
>         :option:`size` to constrain the start and end range of the I/O workload.
>         A percentage can be specified by a number between 1 and 100 followed by '%',
>         for example, ``offset=20%`` to specify 20%.
>
> +.. option:: offset_align=int
> +
> +       If a precentage offset is given, the provided offset is ``blockalign``-ed to
> +       the ``blocksize``. This value will align the initial I/O to a new alignment
> +       Applies to sequential workloads only.

Actually it will should apply to all workloads because a random
workload won't be able to generate an offset that is less than the
aligned offset. I'd go with something like the following:

If set to a non-zero number, the value generated by a percentage
``offset`` is aligned upwards to this value. Defaults to 0 meaning
that a percentage offset is aligned to the minimum block size.

> --- a/filesetup.c
> +++ b/filesetup.c
> @@ -869,10 +869,15 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
>
>         if (o->start_offset_percent > 0) {
>                 /*
> +                * if offset_align is provided, set initial offset
> +                */
> +               if (fio_option_is_set(o, start_offset_align)) {
> +                       align_bs = o->start_offset_align;
> +               /*
>                  * if blockalign is provided, find the min across read, write,
>                  * and trim
>                  */
> -               if (fio_option_is_set(o, ba)) {
> +               } else if (fio_option_is_set(o, ba)) {
>                         align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
>                         align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);

Why check ba here? I don't think we get anything from trying to align
the offset to blockalign given its behaviour.

>                 } else {
> diff --git a/fio.1 b/fio.1
> index 7787ef2..098ca2e 100644
> --- a/fio.1
> +++ b/fio.1
> @@ -913,13 +913,18 @@ should be associated with them.
>  .TP
>  .BI offset \fR=\fPint
>  Start I/O at the provided offset in the file, given as either a fixed size in
> -bytes or a percentage. If a percentage is given, the next \fBblockalign\fR\-ed
> +bytes or a percentage. If a percentage is given, the next \fBbs\fR \fBblockalign\fR\-ed
>  offset will be used. Data before the given offset will not be touched. This
>  effectively caps the file size at `real_size \- offset'. Can be combined with
>  \fBsize\fR to constrain the start and end range of the I/O workload.
>  A percentage can be specified by a number between 1 and 100 followed by '%',
>  for example, `offset=20%' to specify 20%.

See above for documentation suggestions.

>  .TP
> +.BI offset_align \fR=\fPint
> +If a precentage offset is given, the provided offset is \fBblockalign\fR\-ed to
> +the \fBblocksize\fR. This value will align the initial I/O to a new alignment.
> +Applies to sequential workloads only.
> +.TP
>  .BI offset_increment \fR=\fPint
>  If this is provided, then the real offset becomes `\fBoffset\fR + \fBoffset_increment\fR
>  * thread_number', where the thread number is a counter that starts at 0 and
> diff --git a/options.c b/options.c
> index ddcc4e5..a7821d7 100644
> --- a/options.c
> +++ b/options.c
> @@ -2019,6 +2019,17 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
>                 .group  = FIO_OPT_G_INVALID,
>         },
>         {
> +               .name   = "offset_align",
> +               .lname  = "IO offset alignment",
> +               .type   = FIO_OPT_STR_VAL,

Isn't FIO_OPT_INT more appropriate?

> +               .off1   = offsetof(struct thread_options, start_offset_align),
> +               .help   = "Start IO from this offset alignment",
> +               .def    = "0",
> +               .interval = 1024 * 1024,

Actually here's a question - what does .interval do?

> +               .category = FIO_OPT_C_IO,
> +               .group  = FIO_OPT_G_INVALID,
> +       },
> +       {
>                 .name   = "offset_increment",
>                 .lname  = "IO offset increment",
>                 .type   = FIO_OPT_STR_VAL,
> diff --git a/thread_options.h b/thread_options.h
> index 1813cdc..5a037bf 100644
> --- a/thread_options.h
> +++ b/thread_options.h
> @@ -78,6 +78,7 @@ struct thread_options {
>         unsigned long long file_size_low;
>         unsigned long long file_size_high;
>         unsigned long long start_offset;
> +       unsigned long long start_offset_align;
>
>         unsigned int bs[DDIR_RWDIR_CNT];
>         unsigned int ba[DDIR_RWDIR_CNT];
> @@ -355,6 +356,7 @@ struct thread_options_pack {
>         uint64_t file_size_low;
>         uint64_t file_size_high;
>         uint64_t start_offset;
> +       uint64_t start_offset_align;
>
>         uint32_t bs[DDIR_RWDIR_CNT];
>         uint32_t ba[DDIR_RWDIR_CNT];
>
>
>
> Regards,
> Jeff

Thanks for trying this out Jeff!

-- 
Sitsofe | http://sucs.org/~sits/

RE: fio offset with ba

[Jeff Furlong]

>I'd stop referencing blockalign here to avoid confusion
Done.

>Actually it will should apply to all workloads because a random workload won't be able to generate an offset that is less than the aligned offset.
The offset_align will only apply if % is used in offset (not byte offset).  Agreed if sequential or random IO, get_start_offset() is invoked for starting LBA.  Applied updates.

>Why check ba here? I don't think we get anything from trying to align the offset to blockalign given its behaviour.
Done.

>Isn't FIO_OPT_INT more appropriate?
Good point, same as blockalign.

>Actually here's a question - what does .interval do?
Looks like it is used to override the default value of 1 in gopt_new_int():
	interval = 1.0;
	if (o->interval)
		interval = o->interval;
	i->spin = gtk_spin_button_new_with_range(o->minval, maxval, interval);
But your larger question may be why do some options have interval (e.g. offset) and some not have interval (e.g. ioengine).

Here is a v2 patch:



diff --git a/HOWTO b/HOWTO
index 22a5849..e7142c5 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1128,13 +1128,20 @@ I/O type
 .. option:: offset=int
 
 	Start I/O at the provided offset in the file, given as either a fixed size in
-	bytes or a percentage. If a percentage is given, the next ``blockalign``-ed
-	offset will be used. Data before the given offset will not be touched. This
+	bytes or a percentage. If a percentage is given, the generated offset will be
+	aligned to the minimum ``blocksize`` or to the value of ``offset_align`` if
+	provided. Data before the given offset will not be touched. This
 	effectively caps the file size at `real_size - offset`. Can be combined with
 	:option:`size` to constrain the start and end range of the I/O workload.
 	A percentage can be specified by a number between 1 and 100 followed by '%',
 	for example, ``offset=20%`` to specify 20%.
 
+.. option:: offset_align=int
+
+	If set to non-zero value, the byte offset generated by a percentage ``offset``
+	is aligned upwards to this value. Defaults to 0 meaning that a percentage
+	offset is aligned to the minimum block size.
+
 .. option:: offset_increment=int
 
 	If this is provided, then the real offset becomes `offset + offset_increment
diff --git a/cconv.c b/cconv.c
index f809fd5..dc3c4e6 100644
--- a/cconv.c
+++ b/cconv.c
@@ -105,6 +105,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
 	o->file_size_low = le64_to_cpu(top->file_size_low);
 	o->file_size_high = le64_to_cpu(top->file_size_high);
 	o->start_offset = le64_to_cpu(top->start_offset);
+	o->start_offset_align = le64_to_cpu(top->start_offset_align);
 	o->start_offset_percent = le32_to_cpu(top->start_offset_percent);
 
 	for (i = 0; i < DDIR_RWDIR_CNT; i++) {
@@ -548,6 +549,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
 	top->file_size_low = __cpu_to_le64(o->file_size_low);
 	top->file_size_high = __cpu_to_le64(o->file_size_high);
 	top->start_offset = __cpu_to_le64(o->start_offset);
+	top->start_offset_align = __cpu_to_le64(o->start_offset_align);
 	top->start_offset_percent = __cpu_to_le32(o->start_offset_percent);
 	top->trim_backlog = __cpu_to_le64(o->trim_backlog);
 	top->offset_increment = __cpu_to_le64(o->offset_increment);
diff --git a/filesetup.c b/filesetup.c
index 7a602d4..5d7ea5c 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -869,12 +869,10 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
 
 	if (o->start_offset_percent > 0) {
 		/*
-		 * if blockalign is provided, find the min across read, write,
-		 * and trim
+		 * if offset_align is provided, set initial offset
 		 */
-		if (fio_option_is_set(o, ba)) {
-			align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
-			align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);
+		if (fio_option_is_set(o, start_offset_align)) {
+			align_bs = o->start_offset_align;
 		} else {
 			/* else take the minimum block size */
 			align_bs = td_min_bs(td);
diff --git a/fio.1 b/fio.1
index 7787ef2..96d8f11 100644
--- a/fio.1
+++ b/fio.1
@@ -913,13 +913,19 @@ should be associated with them.
 .TP
 .BI offset \fR=\fPint
 Start I/O at the provided offset in the file, given as either a fixed size in
-bytes or a percentage. If a percentage is given, the next \fBblockalign\fR\-ed
-offset will be used. Data before the given offset will not be touched. This
+bytes or a percentage. If a percentage is given, the generated offset will be
+aligned to the minimum \fBblocksize\fR or to the value of \fBoffset_align\fR if
+provided. Data before the given offset will not be touched. This
 effectively caps the file size at `real_size \- offset'. Can be combined with
 \fBsize\fR to constrain the start and end range of the I/O workload.
 A percentage can be specified by a number between 1 and 100 followed by '%',
 for example, `offset=20%' to specify 20%.
 .TP
+.BI offset_align \fR=\fPint
+If set to non-zero value, the byte offset generated by a percentage \fBoffset\fR
+is aligned upwards to this value. Defaults to 0 meaning that a percentage
+offset is aligned to the minimum block size.
+.TP
 .BI offset_increment \fR=\fPint
 If this is provided, then the real offset becomes `\fBoffset\fR + \fBoffset_increment\fR
 * thread_number', where the thread number is a counter that starts at 0 and
diff --git a/options.c b/options.c
index ddcc4e5..e88dc2c 100644
--- a/options.c
+++ b/options.c
@@ -2019,6 +2019,17 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
 		.group	= FIO_OPT_G_INVALID,
 	},
 	{
+		.name	= "offset_align",
+		.lname	= "IO offset alignment",
+		.type	= FIO_OPT_INT,
+		.off1	= offsetof(struct thread_options, start_offset_align),
+		.help	= "Start IO from this offset alignment",
+		.def	= "0",
+		.interval = 1024 * 1024,
+		.category = FIO_OPT_C_IO,
+		.group	= FIO_OPT_G_INVALID,
+	},
+	{
 		.name	= "offset_increment",
 		.lname	= "IO offset increment",
 		.type	= FIO_OPT_STR_VAL,
diff --git a/thread_options.h b/thread_options.h
index 1813cdc..5a037bf 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -78,6 +78,7 @@ struct thread_options {
 	unsigned long long file_size_low;
 	unsigned long long file_size_high;
 	unsigned long long start_offset;
+	unsigned long long start_offset_align;
 
 	unsigned int bs[DDIR_RWDIR_CNT];
 	unsigned int ba[DDIR_RWDIR_CNT];
@@ -355,6 +356,7 @@ struct thread_options_pack {
 	uint64_t file_size_low;
 	uint64_t file_size_high;
 	uint64_t start_offset;
+	uint64_t start_offset_align;
 
 	uint32_t bs[DDIR_RWDIR_CNT];
 	uint32_t ba[DDIR_RWDIR_CNT];



Regards,
Jeff

Re: fio offset with ba

[Jens Axboe]

On 10/25/2017 05:27 PM, Jeff Furlong wrote:
>> Actually here's a question - what does .interval do?
> Looks like it is used to override the default value of 1 in gopt_new_int():
> 	interval = 1.0;
> 	if (o->interval)
> 		interval = o->interval;
> 	i->spin = gtk_spin_button_new_with_range(o->minval, maxval, interval);
>
> But your larger question may be why do some options have interval
> (e.g. offset) and some not have interval (e.g. ioengine).

It's for the GUI, where you want to specify in which increments a value
is adjusted when you use the up and down arrows to change it. It's only
applicable to numberical values, it would not make sense to apply to
something like ioengine or similar.

> diff --git a/filesetup.c b/filesetup.c
> index 7a602d4..5d7ea5c 100644
> --- a/filesetup.c
> +++ b/filesetup.c
> @@ -869,12 +869,10 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
>  
>  	if (o->start_offset_percent > 0) {
>  		/*
> -		 * if blockalign is provided, find the min across read, write,
> -		 * and trim
> +		 * if offset_align is provided, set initial offset
>  		 */
> -		if (fio_option_is_set(o, ba)) {
> -			align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
> -			align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);
> +		if (fio_option_is_set(o, start_offset_align)) {
> +			align_bs = o->start_offset_align;

I'm curious why this drops the 'ba' part?

-- 
Jens Axboe

Re: fio offset with ba

[Sitsofe Wheeler]

On 26 October 2017 at 05:24, Jens Axboe <axboe@kernel.dk> wrote:
> On 10/25/2017 05:27 PM, Jeff Furlong wrote:
>>> Actually here's a question - what does .interval do?
>> Looks like it is used to override the default value of 1 in gopt_new_int():
>>       interval = 1.0;
>>       if (o->interval)
>>               interval = o->interval;
>>       i->spin = gtk_spin_button_new_with_range(o->minval, maxval, interval);
>>
>> But your larger question may be why do some options have interval
>> (e.g. offset) and some not have interval (e.g. ioengine).
>
> It's for the GUI, where you want to specify in which increments a value
> is adjusted when you use the up and down arrows to change it. It's only
> applicable to numberical values, it would not make sense to apply to
> something like ioengine or similar.

You were right Jeff - it was a larger question. Jens thanks for
clearing up its purpose - I missed it was used by the GUI.

>> diff --git a/filesetup.c b/filesetup.c
>> index 7a602d4..5d7ea5c 100644
>> --- a/filesetup.c
>> +++ b/filesetup.c
>> @@ -869,12 +869,10 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
>>
>>       if (o->start_offset_percent > 0) {
>>               /*
>> -              * if blockalign is provided, find the min across read, write,
>> -              * and trim
>> +              * if offset_align is provided, set initial offset
>>                */
>> -             if (fio_option_is_set(o, ba)) {
>> -                     align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
>> -                     align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);
>> +             if (fio_option_is_set(o, start_offset_align)) {
>> +                     align_bs = o->start_offset_align;
>
> I'm curious why this drops the 'ba' part?

blockalign actually only impacts random I/O (see
https://github.com/axboe/fio/issues/341 for someone requesting it to
affect sequential I/O but that's a separate issue). Since each random
I/O will "blockalign itself" we gain nothing from trying to align the
offset generated by offset percentage to it.

-- 
Sitsofe | http://sucs.org/~sits/

Re: fio offset with ba

[Jens Axboe]

On 10/25/2017 11:27 PM, Sitsofe Wheeler wrote:
> On 26 October 2017 at 05:24, Jens Axboe <axboe@kernel.dk> wrote:
>> On 10/25/2017 05:27 PM, Jeff Furlong wrote:
>>>> Actually here's a question - what does .interval do?
>>> Looks like it is used to override the default value of 1 in gopt_new_int():
>>>       interval = 1.0;
>>>       if (o->interval)
>>>               interval = o->interval;
>>>       i->spin = gtk_spin_button_new_with_range(o->minval, maxval, interval);
>>>
>>> But your larger question may be why do some options have interval
>>> (e.g. offset) and some not have interval (e.g. ioengine).
>>
>> It's for the GUI, where you want to specify in which increments a value
>> is adjusted when you use the up and down arrows to change it. It's only
>> applicable to numberical values, it would not make sense to apply to
>> something like ioengine or similar.
> 
> You were right Jeff - it was a larger question. Jens thanks for
> clearing up its purpose - I missed it was used by the GUI.
> 
>>> diff --git a/filesetup.c b/filesetup.c
>>> index 7a602d4..5d7ea5c 100644
>>> --- a/filesetup.c
>>> +++ b/filesetup.c
>>> @@ -869,12 +869,10 @@ uint64_t get_start_offset(struct thread_data *td, struct fio_file *f)
>>>
>>>       if (o->start_offset_percent > 0) {
>>>               /*
>>> -              * if blockalign is provided, find the min across read, write,
>>> -              * and trim
>>> +              * if offset_align is provided, set initial offset
>>>                */
>>> -             if (fio_option_is_set(o, ba)) {
>>> -                     align_bs = (unsigned long long) min(o->ba[DDIR_READ], o->ba[DDIR_WRITE]);
>>> -                     align_bs = min((unsigned long long) o->ba[DDIR_TRIM], align_bs);
>>> +             if (fio_option_is_set(o, start_offset_align)) {
>>> +                     align_bs = o->start_offset_align;
>>
>> I'm curious why this drops the 'ba' part?
> 
> blockalign actually only impacts random I/O (see
> https://github.com/axboe/fio/issues/341 for someone requesting it to
> affect sequential I/O but that's a separate issue). Since each random
> I/O will "blockalign itself" we gain nothing from trying to align the
> offset generated by offset percentage to it.

Gotcha. That's my only comment on the patch, if folks are happy with it,
we can slide it in.

-- 
Jens Axboe