On 12/16/2014 10:40 AM, Stephen Nichols wrote: Hi Jens and Andrey, The fix worked great. Confirmed in bus trace. I adjusted the BS of the original workload to 4K to make it easier to track sequential LBA's and here is a snippet from the trace Command LBA Read FPDMA Queued: 42DD8338 Read FPDMA Queued: 3861F5D7 Write FPDMA Queued: EC Read FPDMA Queued: 3DAD77C5 Write FPDMA Queued: ED Write FPDMA Queued: EE Read FPDMA Queued: 3CFB77D2 Read FPDMA Queued: 33304BF3 Read FPDMA Queued: 350491D5 Read FPDMA Queued: 2D428D0D Write FPDMA Queued: EF Read FPDMA Queued: 15C76871 Write FPDMA Queued: F0 Read FPDMA Queued: 12C6A679 Thanks, Stephen Nichols > > > -----Original Message----- > From: Jens Axboe [mailto:axboe@xxxxxxxxx] > Sent: Sunday, December 14, 2014 6:39 PM > To: Andrey Kuzmin > Cc: Stephen Nichols; fio@xxxxxxxxxxxxxxx > Subject: Re: Sequential Commands are essentially random when in mixed > sequential/random workloads > > On 12/14/2014 08:20 AM, Andrey Kuzmin wrote: >> On Sun, Dec 14, 2014 at 1:53 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: >>> On 12/12/2014 05:23 PM, Stephen Nichols wrote: >>>> Hi all, >>>> >>>> When using fio configuration below.. >>>> >>>> [global] >>>> ioengine=libaio >>>> direct=1 >>>> runtime=600 >>>> bs=32k >>>> iodepth=8 >>>> rw=randrw >>>> rwmixread=80 >>>> percentage_random=100,0 >>>> >>>> [drive1] >>>> filename=/dev/sda >>>> >>>> >>>> I am expecting to see 80% reads, 20% writes where all reads are random and all writes are sequential. I captured a bus trace of traffic to the disk and the bus trace reflected as much with one issue. The write commands are essentially random. Each write begins at a new random LBA. If 2 or more writes occur in a row, the LBA's are sequential based on the block size BUT I feel the heart of this feature would be to emulate a large file write during random access. With that in mind would it be possible for sequential reads or writes within mixed sequential/random workload to remember the last LBA accessed? In this scenario the writes would still only take up 20% of the workload but when a write did occur it should be the next sequential step from the last write. >>>> >>>> >>>> Snippet from the bus trace for reference >>>> >>>> Command LBA >>>> Read FPDMA Queued: 19F3F818 >>>> Read FPDMA Queued: 1CBE2740 >>>> Write FPDMA Queued: 24E35198 >>>> Write FPDMA Queued: 24E351A0 >>>> Read FPDMA Queued: 115A9E10 >>>> Write FPDMA Queued: A3C1968 >>>> Read FPDMA Queued: 20B89488 >>>> Write FPDMA Queued: 336EE0D0 >>>> Write FPDMA Queued: 336EE0D8 >>>> >>>> >>>> >>>> Let me know what you think, this feature may be working as intended but it seemed off to me. >>> >>> Would be easy enough to fix, we just need to track last offset per >>> data direction. Does the attached work for you? Totally untested, >>> will test on Monday. >> >> Looks like fixed. > > Thanks for verifying, Andrey. After taking a second look, looks sane to me after all. Lucky punch! > > Stephen, the fix has been committed, so if you just update to the latest git, it should hopefully work for you as well. Please report back when you have tested it. > > -- > Jens Axboe > ��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
