* Jens Axboe <jaxboe@xxxxxxxxxxxx> wrote: > On 2010-11-10 09:22, Sebastian Kayser wrote: > > Just to make sure my understanding is correct: > > - direct=1 should mitigate (disable?) OS caching effects > > - sync=1, iodepth=1 should make sure that an I/O has really made it to > > disk before the next on is issued, i.e. should de-facto disable > > I/O coalescing or device caching > > > > Are these sane/valid assumptions? > > Yes, your assumptions are valid. I think the issue here is that you give > randwrite, but don't also specify that you want overwrites. So what > happens is that the file will be truncated and then randomly written, > allowing the file system to place randomly chosen file block together. > If you remove the test file and re-run with overwrite=1 added, then see > if those results are more in line with what you expect. Thanks for the additional aspect! So the possible pitfall is that w/o overwrite=1 the test file could be sparse and the file system then re-arrange random file addresses to fall onto consecutive device blocks? (If so, wouldn't that be evil / deliberate data fragmentation?) Tested it again with overwrite=1, same IOPS figures. Test file size as measured with du -ks is the same in both cases btw. (which combined with the limited runtime=120 doesn't seem to indicate sparseness in case of overwrite=0, right?). What I will do now is to export the whole 2TB of the disk (instead of just 10GB) and increase size= to see whether that makes any difference (hopefully). Other than that, further ideas? Sebastian -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
