[Question] Sequential mesuaring and filename option

[Question] Sequential mesuaring and filename option

[Nakajima Akira]

Hi.

I'm using fio for the first time. Sorry for the basic question.

On RHEL 8.3
# fio -filename=/mnt/testfile -direct=1 -ioengine=libaio -rw=write 
-bs=1m -size=5G -numjobs=1 -runtime=60 -group_reporting -name=test
IOPS=366, BW=366MiB/s

But when -numjobs=10
IOPS=3358, BW=3358MiB/s
This is 5 times faster than the physical speed of the HDD I am using 
(600MB/s).
Similar results are obtained with Sequential write.
Random read/write is fine.(Results are within 600MB/s)

https://fio.readthedocs.io/en/latest/fio_man.html#target-file-device
I refer above and use -directory=/mnt/testdir instead of -filename gave 
good results.

Am I using the -filename option incorrectly?

I confirmed this with the following ver.
fio-3.26(build from git), fio-3.19-3.el8, fio-3.1-1.el7


Thanks.
Nakajima.

Re: [Question] Sequential mesuaring and filename option

[Erwan Velu]

Le 13/04/2021 à 08:13, Nakajima Akira a écrit :
> Hi.
>
> I'm using fio for the first time. Sorry for the basic question.
>
> On RHEL 8.3
> # fio -filename=/mnt/testfile -direct=1 -ioengine=libaio -rw=write 
> -bs=1m -size=5G -numjobs=1 -runtime=60 -group_reporting -name=test
> IOPS=366, BW=366MiB/s
>
> But when -numjobs=10
> IOPS=3358, BW=3358MiB/s
> This is 5 times faster than the physical speed of the HDD I am using 
> (600MB/s).
> Similar results are obtained with Sequential write.
> Random read/write is fine.(Results are within 600MB/s)
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffio.readthedocs.io%2Fen%2Flatest%2Ffio_man.html%23target-file-device&data=04%7C01%7Ce.velu%40criteo.com%7Cdd41a8193e6048f16cc408d8fe441b34%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637538915767435166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7jscmG7bnj%2BSBE%2BgbwVWNbz%2BTQhhckXAP%2Bl7xa%2F%2FuHo%3D&reserved=0 
>
> I refer above and use -directory=/mnt/testdir instead of -filename 
> gave good results.
>
> Am I using the -filename option incorrectly? 


Hey,

You are performing your benchmark against the filesystem which uses the 
memory as cache. So here, you are benchmarking your memory (which is 
correlated by the 3GB/sec speed).

You can use direct=1 to avoid using the buffer as per 
https://fio.readthedocs.io/en/latest/fio_doc.html#i-o-type

If you want to test the disk itself, not the filesystem, it would be 
better to use the block device directly (/dev/sd<x>) and remove this 
unecessary layer.

Erwan,

Re: [Question] Sequential mesuaring and filename option

[Nakajima Akira]

On 2021/04/13 23:21, Erwan Velu wrote:
> Le 13/04/2021 à 08:13, Nakajima Akira a écrit :
>> Hi.
>>
>> I'm using fio for the first time. Sorry for the basic question.
>>
>> On RHEL 8.3
>> # fio -filename=/mnt/testfile -direct=1 -ioengine=libaio -rw=write
>> -bs=1m -size=5G -numjobs=1 -runtime=60 -group_reporting -name=test
>> IOPS=366, BW=366MiB/s
>>
>> But when -numjobs=10
>> IOPS=3358, BW=3358MiB/s
>> This is 5 times faster than the physical speed of the HDD I am using
>> (600MB/s).
>> Similar results are obtained with Sequential write.
>> Random read/write is fine.(Results are within 600MB/s)
>>
>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffio.readthedocs.io%2Fen%2Flatest%2Ffio_man.html%23target-file-device&data=04%7C01%7Ce.velu%40criteo.com%7Cdd41a8193e6048f16cc408d8fe441b34%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637538915767435166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7jscmG7bnj%2BSBE%2BgbwVWNbz%2BTQhhckXAP%2Bl7xa%2F%2FuHo%3D&reserved=0
>>
>> I refer above and use -directory=/mnt/testdir instead of -filename
>> gave good results.
>>
>> Am I using the -filename option incorrectly?
> 
> 
> Hey,
> 
> You are performing your benchmark against the filesystem which uses the
> memory as cache. So here, you are benchmarking your memory (which is
> correlated by the 3GB/sec speed).
> 
> You can use direct=1 to avoid using the buffer as per
> https://fio.readthedocs.io/en/latest/fio_doc.html#i-o-type
> 
> If you want to test the disk itself, not the filesystem, it would be
> better to use the block device directly (/dev/sd<x>) and remove this
> unecessary layer.
> 
> Erwan,
> 

Hi.

I am using direct=1.
I'd like to test LUKS2 encryption speed, so need xfs/ext4 filesystem.

Thanks.
Nakajima.

Re: [Question] Sequential mesuaring and filename option

[Nakajima Akira]

On 2021/04/15 2:57, Sitsofe Wheeler wrote:
 >
 >
 > On Wed, 14 Apr 2021 at 13:21, Nakajima Akira 
<nakajima.akira@nttcom.co.jp <mailto:nakajima.akira@nttcom.co.jp>> wrote:
 >
 >     On 2021/04/13 23:21, Erwan Velu wrote:
 >      > Le 13/04/2021 à 08:13, Nakajima Akira a écrit :
 >      >> Hi.
 >      >>
 >      >> I'm using fio for the first time. Sorry for the basic question.
 >      >>
 >      >> On RHEL 8.3
 >      >> # fio -filename=/mnt/testfile -direct=1 -ioengine=libaio 
-rw=write
 >      >> -bs=1m -size=5G -numjobs=1 -runtime=60 -group_reporting 
-name=test
 >      >> IOPS=366, BW=366MiB/s
 >      >>
 >      >> But when -numjobs=10
 >      >> IOPS=3358, BW=3358MiB/s
 >      >> This is 5 times faster than the physical speed of the HDD I 
am using
 >      >> (600MB/s).
 >      >> Similar results are obtained with Sequential write.
 >      >> Random read/write is fine.(Results are within 600MB/s)
 >      >>
 >      >>
 > 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffio.readthedocs.io%2Fen%2Flatest%2Ffio_man.html%23target-file-device&amp;data=04%7C01%7Ce.velu%40criteo.com%7Cdd41a8193e6048f16cc408d8fe441b34%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637538915767435166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=7jscmG7bnj%2BSBE%2BgbwVWNbz%2BTQhhckXAP%2Bl7xa%2F%2FuHo%3D&amp;reserved=0
 > 
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffio.readthedocs.io%2Fen%2Flatest%2Ffio_man.html%23target-file-device&amp;data=04%7C01%7Ce.velu%40criteo.com%7Cdd41a8193e6048f16cc408d8fe441b34%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637538915767435166%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=7jscmG7bnj%2BSBE%2BgbwVWNbz%2BTQhhckXAP%2Bl7xa%2F%2FuHo%3D&amp;reserved=0>
 >      >>
 >      >> I refer above and use -directory=/mnt/testdir instead of 
-filename
 >      >> gave good results.
 >      >>
 >      >> Am I using the -filename option incorrectly?
 >      >
 >      >
 >      > Hey,
 >      >
 >      > You are performing your benchmark against the filesystem which
 >     uses the
 >      > memory as cache. So here, you are benchmarking your memory 
(which is
 >      > correlated by the 3GB/sec speed).
 >      >
 >      > You can use direct=1 to avoid using the buffer as per
 >      > https://fio.readthedocs.io/en/latest/fio_doc.html#i-o-type
 >     <https://fio.readthedocs.io/en/latest/fio_doc.html#i-o-type>
 >      >
 >      > If you want to test the disk itself, not the filesystem, it 
would be
 >      > better to use the block device directly (/dev/sd<x>) and 
remove this
 >      > unecessary layer.
 >      >
 >      > Erwan,
 >      >
 >
 >     Hi.
 >
 >     I am using direct=1.
 >     I'd like to test LUKS2 encryption speed, so need xfs/ext4 filesystem.
 >
 >
 > I don't know if caching is happening nonetheless (maybe it will 
because the data has to be transformed before it can reach the disk due 
to encryption). One approach is to do I/O over an area three times that 
of your physical RAM (in your case you can just adjust size) to defeat 
the benefit of caching and to force flushing. Does that change the 
results at all?
 >
 > --
 > Sitsofe


Hi.

Sorry. Due to my company's email sender domain restrictions,
  it could not be sent to gmail.


Above is the result on unencrypted ext4/xfs.
Similar results are obtained on encrypted ext4/xfs.


Since the memory is 24GB, I tried it with 72GB + α = 76GB.

# fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m 
-size=76G -runtime=60 -numjobs=1 -group_reporting -name=a
   write: IOPS=195, BW=195MiB/s (205MB/s)(11.4GiB/60023msec)

# fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m 
-size=76G -runtime=60 -numjobs=10 -group_reporting -name=a
   write: IOPS=1622, BW=1622MiB/s (1701MB/s)(95.1GiB/60042msec)

# fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m 
-size=76G -runtime=300 -numjobs=10 -group_reporting -name=a
   write: IOPS=1879, BW=1880MiB/s (1971MB/s)(551GiB/300004msec)


Up to numjobs = about 10, it increases in proportion to the value of 
numjobs.


Thanks.
Nakajima.

Re: [Question] Sequential mesuaring and filename option

[Nakajima Akira]

On 2021/04/16 4:37, Sitsofe Wheeler wrote:
> On Thu, 15 Apr 2021 at 03:49, Nakajima Akira 
> <nakajima.akira@nttcom.co.jp <mailto:nakajima.akira@nttcom.co.jp>> wrote:
> 
> 
>     Hi.
> 
>     Sorry. Due to my company's email sender domain restrictions,
>        it could not be sent to gmail.
> 
> 
>     Above is the result on unencrypted ext4/xfs.
>     Similar results are obtained on encrypted ext4/xfs.
> 
> 
>     Since the memory is 24GB, I tried it with 72GB + α = 76GB.
> 
>     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>     -size=76G -runtime=60 -numjobs=1 -group_reporting -name=a
>         write: IOPS=195, BW=195MiB/s (205MB/s)(11.4GiB/60023msec)
> 
>     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>     -size=76G -runtime=60 -numjobs=10 -group_reporting -name=a
>         write: IOPS=1622, BW=1622MiB/s (1701MB/s)(95.1GiB/60042msec)
> 
>     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>     -size=76G -runtime=300 -numjobs=10 -group_reporting -name=a
>         write: IOPS=1879, BW=1880MiB/s (1971MB/s)(551GiB/300004msec)
> 
> 
> Ah, that numjobs value is REALLY important for the type of job file 
> you have! Using numjobs on the same filename can lead to reuse of the 
> same area (think job 1 and job 2 writing the same blocks in lockstep) 
> which may in turn lead to not all I/Os being sent down to the disk if 
> they are close enough together. This may make a nonsense of your 
> benchmark...
> 
>     Up to numjobs = about 10, it increases in proportion to the value of
>     numjobs.
> 
> -- 
> Sitsofe

Hi.


Now I tried, but these had the same results.
   (twice as much as numjobs=1)
-filename=/mnt/test1:/mnt/test2
-filename=/dev/sdb  (after umount /mnt)

# fio -filename=xxx -direct=1 -ioengine=libaio -rw=write -bs=1m -size=8G 
-runtime=60 -numjobs=2 -group_reporting -name=a


Using -directory instead of -filename is only way to get correct result?


Thanks.
Nakajima.

Re: [Question] Sequential mesuaring and filename option

[Sitsofe Wheeler]

Hey,

On Fri, 16 Apr 2021 at 04:49, Nakajima Akira
<nakajima.akira@nttcom.co.jp> wrote:
>
> On 2021/04/16 4:37, Sitsofe Wheeler wrote:
> > On Thu, 15 Apr 2021 at 03:49, Nakajima Akira
> > <nakajima.akira@nttcom.co.jp <mailto:nakajima.akira@nttcom.co.jp>> wrote:
> >
> >
> >     Hi.
> >
> >     Sorry. Due to my company's email sender domain restrictions,
> >        it could not be sent to gmail.
> >
> >
> >     Above is the result on unencrypted ext4/xfs.
> >     Similar results are obtained on encrypted ext4/xfs.
> >
> >
> >     Since the memory is 24GB, I tried it with 72GB + α = 76GB.
> >
> >     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
> >     -size=76G -runtime=60 -numjobs=1 -group_reporting -name=a
> >         write: IOPS=195, BW=195MiB/s (205MB/s)(11.4GiB/60023msec)
> >
> >     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
> >     -size=76G -runtime=60 -numjobs=10 -group_reporting -name=a
> >         write: IOPS=1622, BW=1622MiB/s (1701MB/s)(95.1GiB/60042msec)
> >
> >     # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
> >     -size=76G -runtime=300 -numjobs=10 -group_reporting -name=a
> >         write: IOPS=1879, BW=1880MiB/s (1971MB/s)(551GiB/300004msec)
> >
> >
> > Ah, that numjobs value is REALLY important for the type of job file
> > you have! Using numjobs on the same filename can lead to reuse of the
> > same area (think job 1 and job 2 writing the same blocks in lockstep)
> > which may in turn lead to not all I/Os being sent down to the disk if
> > they are close enough together. This may make a nonsense of your
> > benchmark...
> >
> >     Up to numjobs = about 10, it increases in proportion to the value of
> >     numjobs.
> >
> > --
> > Sitsofe
>
> Hi.
>
>
> Now I tried, but these had the same results.
>    (twice as much as numjobs=1)
> -filename=/mnt/test1:/mnt/test2
> -filename=/dev/sdb  (after umount /mnt)
>
> # fio -filename=xxx -direct=1 -ioengine=libaio -rw=write -bs=1m -size=8G
> -runtime=60 -numjobs=2 -group_reporting -name=a
>
>
> Using -directory instead of -filename is only way to get correct result?

That would work but it depends on what "correct" means :-) The problem
with your jobs above is that you have not eliminated the possibility
of two or more jobs still writing the same area at the same time (the
colon syntax in filename just tells fio it might have to pick a
different file to last time - see
https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-file-service-type
further info). If all jobs are switching files in lockstep on each I/O
what is stopping collisions?

I'll illustrate the original scenario but simplified a bit:

job1: | 0 | 1 | 2 | ...
job2: | 0 | 1 | 2 | ...

Time is flowing from left to right and the numbers represent the LBA
being written within a given period. In this case in the first
"instant" LBA 0 is being written twice, LBA 1 is being written twice
in the second instant and LBA 2 is being written twice in the third
instant. Sending a write for an LBA that still has an incomplete
in-flight write against it typically results in unspecified behaviour
- we just don't know what sort of "optimisations" might kick in
because we've created a scenario where we've told the system we can't
care about the result of every write...

Ideas for how to avoid getting into the above scenario with numjobs:
- Have each job work with a *different* file to any other job so they
can't collide. As you suggest you can use directory and let fio make
up the filename so each job is working on a seperate file (filename
must NOT be set!).
- Have each job work on a different part of the same "file" so they
can't collide. This requires some sort of partitioning and if you
choose to do this size
(https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-size
) and offset_increment
(https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-offset-increment
) may help. Obviously each "region" shouldn't be too small but you get
the idea.

I don't know your circumstances but a part of me wonders if it would
have been easier to just increase iodepth and stick a single job to
get increased simultaneous I/O.

--
Sitsofe

Re: [Question] Sequential mesuaring and filename option

[Nakajima Akira]

On 2021/04/16 14:10, Sitsofe Wheeler wrote:
> Hey,
> 
> On Fri, 16 Apr 2021 at 04:49, Nakajima Akira
> <nakajima.akira@nttcom.co.jp> wrote:
>>
>> On 2021/04/16 4:37, Sitsofe Wheeler wrote:
>>> On Thu, 15 Apr 2021 at 03:49, Nakajima Akira
>>> <nakajima.akira@nttcom.co.jp <mailto:nakajima.akira@nttcom.co.jp>> wrote:
>>>
>>>
>>>      Hi.
>>>
>>>      Sorry. Due to my company's email sender domain restrictions,
>>>         it could not be sent to gmail.
>>>
>>>
>>>      Above is the result on unencrypted ext4/xfs.
>>>      Similar results are obtained on encrypted ext4/xfs.
>>>
>>>
>>>      Since the memory is 24GB, I tried it with 72GB + α = 76GB.
>>>
>>>      # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>>>      -size=76G -runtime=60 -numjobs=1 -group_reporting -name=a
>>>          write: IOPS=195, BW=195MiB/s (205MB/s)(11.4GiB/60023msec)
>>>
>>>      # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>>>      -size=76G -runtime=60 -numjobs=10 -group_reporting -name=a
>>>          write: IOPS=1622, BW=1622MiB/s (1701MB/s)(95.1GiB/60042msec)
>>>
>>>      # fio -filename=/testfile -direct=1 -ioengine=libaio -rw=write -bs=1m
>>>      -size=76G -runtime=300 -numjobs=10 -group_reporting -name=a
>>>          write: IOPS=1879, BW=1880MiB/s (1971MB/s)(551GiB/300004msec)
>>>
>>>
>>> Ah, that numjobs value is REALLY important for the type of job file
>>> you have! Using numjobs on the same filename can lead to reuse of the
>>> same area (think job 1 and job 2 writing the same blocks in lockstep)
>>> which may in turn lead to not all I/Os being sent down to the disk if
>>> they are close enough together. This may make a nonsense of your
>>> benchmark...
>>>
>>>      Up to numjobs = about 10, it increases in proportion to the value of
>>>      numjobs.
>>>
>>> --
>>> Sitsofe
>>
>> Hi.
>>
>>
>> Now I tried, but these had the same results.
>>     (twice as much as numjobs=1)
>> -filename=/mnt/test1:/mnt/test2
>> -filename=/dev/sdb  (after umount /mnt)
>>
>> # fio -filename=xxx -direct=1 -ioengine=libaio -rw=write -bs=1m -size=8G
>> -runtime=60 -numjobs=2 -group_reporting -name=a
>>
>>
>> Using -directory instead of -filename is only way to get correct result?
> 
> That would work but it depends on what "correct" means :-) The problem
> with your jobs above is that you have not eliminated the possibility
> of two or more jobs still writing the same area at the same time (the
> colon syntax in filename just tells fio it might have to pick a
> different file to last time - see
> https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-file-service-type
> further info). If all jobs are switching files in lockstep on each I/O
> what is stopping collisions?
> 
> I'll illustrate the original scenario but simplified a bit:
> 
> job1: | 0 | 1 | 2 | ...
> job2: | 0 | 1 | 2 | ...
> 
> Time is flowing from left to right and the numbers represent the LBA
> being written within a given period. In this case in the first
> "instant" LBA 0 is being written twice, LBA 1 is being written twice
> in the second instant and LBA 2 is being written twice in the third
> instant. Sending a write for an LBA that still has an incomplete
> in-flight write against it typically results in unspecified behaviour
> - we just don't know what sort of "optimisations" might kick in
> because we've created a scenario where we've told the system we can't
> care about the result of every write...
> 
> Ideas for how to avoid getting into the above scenario with numjobs:
> - Have each job work with a *different* file to any other job so they
> can't collide. As you suggest you can use directory and let fio make
> up the filename so each job is working on a seperate file (filename
> must NOT be set!).
> - Have each job work on a different part of the same "file" so they
> can't collide. This requires some sort of partitioning and if you
> choose to do this size
> (https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-size
> ) and offset_increment
> (https://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-offset-increment
> ) may help. Obviously each "region" shouldn't be too small but you get
> the idea.
> 
> I don't know your circumstances but a part of me wonders if it would
> have been easier to just increase iodepth and stick a single job to
> get increased simultaneous I/O.
> 
> --
> Sitsofe
> 

Hi.

Thank you very mush for the commentary.
By adding -offset_increment = x%, I got the same result with -filename 
as with -directory.

 > job1: | 0 | 1 | 2 | ...
 > job2: | 0 | 1 | 2 | ...

 > In this case in the first
 > "instant" LBA 0 is being written twice, LBA 1 is being written twice
 > in the second instant and LBA 2 is being written twice in the third
 > instant.

Is this a bug of fio?
I don't understand the purpose of the above operation.
Is there anyone who expects this behavior and measures it?
   (Despite -direct=1, Result is far exceeds the physical speed of the HDD)


Thanks.
Nakajima.

Re: [Question] Sequential mesuaring and filename option

[Sitsofe Wheeler]

On Fri, 16 Apr 2021 at 08:12, Nakajima Akira
<nakajima.akira@nttcom.co.jp> wrote:
>
> Thank you very mush for the commentary.
> By adding -offset_increment = x%, I got the same result with -filename
> as with -directory.
>
>  > job1: | 0 | 1 | 2 | ...
>  > job2: | 0 | 1 | 2 | ...
>
>  > In this case in the first
>  > "instant" LBA 0 is being written twice, LBA 1 is being written twice
>  > in the second instant and LBA 2 is being written twice in the third
>  > instant.
>
> Is this a bug of fio?
> I don't understand the purpose of the above operation.
> Is there anyone who expects this behavior and measures it?
>    (Despite -direct=1, Result is far exceeds the physical speed of the HDD)

I personally don't consider it a bug - it's not fio doing the
"optimisation". There could be some pathological reason you need such
a workload (e.g. you have to test your disk doesn't just die because
it's actually a legal thing to do) and there are certain disks where
the outcome IS strictly defined (I have a vague recollection about
SCSI TASK attribute ORDERED). Ultimately, it's the result of combining
things that make sense separately and the combination leading to a
non-intuitive result. Sometimes there's no escape from having a good
model of why you get the results you do - another popular case where
things exceed physical speeds is when your data consists of all zeroes
and you're writing to an I/O stack that does compression. You have to
know enough to explain the outcome and why it may not reflect what you
see in "real life"...

Having said that, would you like to submit a patch to update the
documentation with a warning?

-- 
Sitsofe

Re: [Question] Sequential mesuaring and filename option

[Nakajima Akira]

On 2021/04/17 3:02, Sitsofe Wheeler wrote:
> On Fri, 16 Apr 2021 at 08:12, Nakajima Akira
> <nakajima.akira@nttcom.co.jp> wrote:
>>
>> Thank you very mush for the commentary.
>> By adding -offset_increment = x%, I got the same result with -filename
>> as with -directory.
>>
>>   > job1: | 0 | 1 | 2 | ...
>>   > job2: | 0 | 1 | 2 | ...
>>
>>   > In this case in the first
>>   > "instant" LBA 0 is being written twice, LBA 1 is being written twice
>>   > in the second instant and LBA 2 is being written twice in the third
>>   > instant.
>>
>> Is this a bug of fio?
>> I don't understand the purpose of the above operation.
>> Is there anyone who expects this behavior and measures it?
>>     (Despite -direct=1, Result is far exceeds the physical speed of the HDD)
> 
> I personally don't consider it a bug - it's not fio doing the
> "optimisation". There could be some pathological reason you need such
> a workload (e.g. you have to test your disk doesn't just die because
> it's actually a legal thing to do) and there are certain disks where
> the outcome IS strictly defined (I have a vague recollection about
> SCSI TASK attribute ORDERED). Ultimately, it's the result of combining
> things that make sense separately and the combination leading to a
> non-intuitive result. Sometimes there's no escape from having a good
> model of why you get the results you do - another popular case where
> things exceed physical speeds is when your data consists of all zeroes
> and you're writing to an I/O stack that does compression. You have to
> know enough to explain the outcome and why it may not reflect what you
> see in "real life"...
> 
> Having said that, would you like to submit a patch to update the
> documentation with a warning?



I understand it is a specification.
I'm enough because I just want to know whether it is a spec or a bug, 
and what options can give me the results I wanted.
All resolved.
Thank you very much.

Nakajima.