On 2021/04/17 3:02, Sitsofe Wheeler wrote:
On Fri, 16 Apr 2021 at 08:12, Nakajima Akira
<nakajima.akira@xxxxxxxxxxxx> 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.
