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.

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.

     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?


  • 1
    How exactly are you expecting this to work? – mattdm Aug 12 '16 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 Aug 12 '16 at 20:15
  • @mattdm I expect that two read and write are served fair enough (at least with cfq scheduler) – syko Aug 12 '16 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 Aug 12 '16 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 Aug 12 '16 at 20:23

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.