1

I am checking whether the linux file system i/o scheduler prioritizes the write operation over the read operation. The linux version is 3.10.0-327.el7.x86_64

I performed the following experiments where write and read operations should occur concurrently.

disk_dir=/mnt/ssd
nohup fio --name=${disk_dir}/seqread --ioengine=sync --iodepth=1 --rw=read --bs=4096k --direct=0 --size=10240M --numjobs=1 --runtime=600 --group_reporting &
nohup fio --name=${disk_dir}/seqwrite --ioengine=sync --iodepth=1 --rw=write --bs=4096k --direct=0 --size=10240M --numjobs=1 --runtime=600 --group_reporting &

I measured the disk I/O bandwidth usage by dstat and found that the read and write operations does not occur concurrently.

         Disk
     Read   Write
... |3072k  241M|  13k 4211B|   0     0 |3737  2062
... |3072k  258M|  13k 4308B|   0     0 |3532  2676
... |3584k  260M|  16k 4793B|   0     0 |3404  2057
... |3072k  261M|  13k 4211B|   0     0 |3438  2565
...
... (After Write operations all finished)
... 
... | 449M   40k|  13k 4211B|   0     0 |4752  5130
... | 449M   42k|  13k 4308B|   0     0 |4973  5861
... | 428M    0 |  16k 4793B|   0     0 |4630  4990
... | 382M    0 |  13k 4211B|   0     0 |4306  5206

Either Read or Write operation waits for another to be finished!

The results with the different schedulers in Linux were the same.

noop, deadline: They prioritize Write.
cfq: It prioritizes Read.

Am I missing something? Is the experiment itself wrong? Can any one give me an idea on it?

Thanks

Improve this question
7
  • 1
    How exactly are you expecting this to work?
    – mattdm
    Commented Aug 12, 2016 at 20:12
  • It actually makes much more sense to commit write operations first should there be a balanced decision on which one to prioritize. Doing both operations more simultaneously would actually make the whole task (both operations) much slower.
    – Julie Pelletier
    Commented Aug 12, 2016 at 20:15
  • @mattdm I expect that two read and write are served fair enough (at least with cfq scheduler)
    – syko
    Commented Aug 12, 2016 at 20:15
  • @JuliePelletier I aggree on your theory. One interesting point is that when I used 'cfq' scheduler, read operation is prioritized. Another interesting point is that according to a documentation in web deadline operation is designed to prioritize read operations (which is not true in the above experiment)
    – syko
    Commented Aug 12, 2016 at 20:17
  • I'm not familiar with that document but as you noted, the choice of scheduler can make an impact on that decision.
    – Julie Pelletier
    Commented Aug 12, 2016 at 20:23

1 Answer 1

Reset to default
1

I/O schedulers are way more complex that you seem to assume. For example, choosing cfq is just the top of the iceberg - there are tons of tuning parameters, see https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt

Also note as you are not using block device directly, but over some filesystem, the choice of fs (and its tuning params) will be a factor too.

So beware, your tuning might just make thing much worse in the end.

But for this specific example, you could try deadline with write_starved to tune it to be less write-oriented.

https://www.kernel.org/doc/Documentation/block/deadline-iosched.txt

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .