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? -- Sitsofe
