On 28 October 2017 at 09:37, Paolo Valente <paolo.valente@xxxxxxxxxx> wrote: > > Tested, it does solve the problem. As a side note, and if useful for > you, the throughput is much higher with sequential reads and direct=0 > (4.14-rc5, virtual disk on an SSD). It happens because of merges, > which seem to not occur with direct=1. I thought direct I/O skipped > buffering, but still enjoyed features as request merging, but probably > I'm just wrong. > > Thanks for addressing this caching issue, > Paolo I think the window for merging is smaller but non-zero with direct=1 - remember all the I/Os must arrive close enough together to be merged and if fio is doing its submit one in each batch/send one new as soon as one completes default behaviour the odds of that happening are very small. Do you have an iodepth greater than one and are you using an async I/O engine? For example: dd if=/dev/zero of=/mnt/iotrace/fio.tmp bs=1M count=1 oflag=sync fio --filename /mnt/iotrace/fio.tmp --size=1M --rw=write --ioengine=libaio --direct=1 --bs=512 --iodepth 32 --name=merge --time_based --runtime=15s --iodepth=32 --iodepth_batch=32 --iodepth_low=1 [...] Disk stats (read/write): sdb: ios=0/172944, merge=0/14619, ticks=0/286476, in_queue=286200, util=97.74% -- Sitsofe | http://sucs.org/~sits/ -- 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
