为什么在文件系统中写入看起来优先于读取? (或相反亦然)

为什么在文件系统中写入看起来优先于读取? (或相反亦然)

我正在检查 Linux 文件系统 I/O 调度程序是否优先考虑写入操作而不是读取操作。 linux版本是3.10.0-327.el7.x86_64

我进行了以下实验,其中写入和读取操作应同时发生。

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 &

我通过dstat测量了磁盘I/O带宽使用情况,发现读写操作不是同时发生的。

         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

读取或写入操作需要等待另一个操作完成!

Linux 中不同调度程序的结果是相同的。

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

我错过了什么吗?难道实验本身就是错误的吗?任何人都可以给我一个想法吗?

谢谢

答案1

I/O 调度程序比您想象的要复杂得多。例如,选择cfq只是冰山一角 - 有大量的调整参数,请参阅https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt

另请注意,由于您不是直接使用块设备,而是在某些文件系统上使用 fs (和它是调整参数)也将是一个因素。

所以要小心,你的调整最终可能会让事情变得更糟。

但对于这个特定的示例,您可以尝试deadlinewrite_starved其调整为不那么面向写入。

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

相关内容