Odd iozone results [LWN.net]

Odd iozone results

Posted Jan 31, 2012 7:36 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Odd iozone results by sbergman27
Parent article: XFS: the filesystem of the future?

Maybe I missed it but I think thats the first time I have seen mention of the runtime for the 16kb workload 2.5m is smaller than 3h or whatever the estimate was for the previous test. Tat would be interesting to characterize but It might also be an error in testing. I notice that Jim has responded and pointed out hat some of your estimates of seek time are orders of magnitude high which is causing some of the misunderstanding.

(Log in to post comments)

Odd iozone results

Posted Jan 31, 2012 8:30 UTC (Tue) by sbergman27 (guest, #10767) [Link]

Let he who has never made a spelling blunder cast the first stone. Earlier, I was posting from the default Firefox in SL 6.1. Expecting it to catch my speeling errors inline. I made several posts before realizing that the damned thing was completely nonfunctional, and was too mortified to go back and look.

I'm in Chrome now. And it caught "speeling" quite handily.

RickMoen mentioned something about a "sixty second window" for LWN.net posts. I've never noticed any sort of window at all. As soon as I hit "Publish comment" my mistakes are frozen for all eternity.

Sometimes it's a comfort to know that no one really cares about my posts. ;-)

-Steve

Odd iozone results

Posted Jan 31, 2012 16:28 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I think that was a different thing, IIUC Rick just posted something incorrect and someone called him on it 60s before he replied to his own post with the correction and he seemed a little embarrassed and miffed.

Odd iozone results

Posted Jan 31, 2012 8:19 UTC (Tue) by sbergman27 (guest, #10767) [Link]

We're probably focusing a bit too much on random read/write times when there is no evidence or rationale for thinking that the Mixed Workload phase is random read/write. Dave threw that in for reasons which are unclear. There is no evidence from the iozone output, or from its man page, to support the assertion.

If random i/o were the major factor in Mixed Workload, why does moving from a 4k block size take me from such a dismal data rate to nearly the peak sequential read/write data rate for the drive? It makes no sense.

That's the significant question. Why does increasing the record size by a factor of 4 result in such a dramatic increase in throughput?

And BTW, I have not yet explicitly congratulated the XFS team on fact that XFS is now nearly as fast as EXT4 on small system hardware. At least in this particular benchmark. So I will offer my congratulations now.

-Steve

Odd iozone results

Posted Jan 31, 2012 10:59 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]

one thing to remember, in the general case writes can be cached, but the application pauses for reads.

If you do a sequential read test, readahead comes to your rescue, but if you are doing a mixed test, especially where the working set exceeds ram, you can end up with the application stalling waiting for a read and thus introducing additional delays between disk actions.

I don't know exactly what iozone is doing for it's mixed test, but this sort of drastic slowdown is not uncommon.

Also, if you are using a journaling filesystem, there are additional delays as the journal is updated (each write that touches the journal turns in to at least two writes, potentially with an expensive seek between them)

I would suggest running the same test on ext2 (or ext4 with the journal disabled) and see what you get.

Odd iozone results

Posted Jan 31, 2012 17:55 UTC (Tue) by jimparis (subscriber, #38647) [Link]

> We're probably focusing a bit too much on random read/write times when there is no evidence or rationale for thinking that the Mixed Workload phase is random read/write. Dave threw that in for reasons which are unclear. There is no evidence from the iozone output, or from its man page, to support the assertion.

From what I can tell by reading the source code, it is a mix where half of the threads are doing random reads, and half of the threads are doing random writes.