为什么写 O_DIRECT 和 O_SYNC 仍然导致 io 合并？

Question

大家

最近，我用fio做了一些测试来测试我的磁盘性能。我配置fio使用direct io和O_SYNC，下面是我的配置

[global]
invalidate=0    # mandatory
direct=1
sync=1
thread=1
norandommap=1
runtime=10000
time_based=1

[write4k-rand]
stonewall
group_reporting
bs=4k
size=1g
rw=randwrite
numjobs=1
iodepth=1

但是，当我在 fio 为运行时通过 iostat 监视磁盘性能时，我看到了以下输出。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.12    0.00    0.08    3.81    0.00   95.98

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    39.50    0.00  176.00     0.00  1648.00     9.36     1.02    5.81   5.65  99.50

wrqm/s 是 39.50。 stop fio的话，wrqm/s就是0。为什么我用O_SYNC做direct io的时候还有io merge？请帮助我。

谢谢:-)

Answer 1

在 Linux 上，直接执行 I/O 并不意味着 "do this exact I/O" - 这是绕过 Linux 的页面缓存的提示。在撰写本文时，open man page 说的是关于 O_DIRECT:

Try to minimize cache effects of the I/O to and from this file.

这意味着诸如 Linux I/O 调度器之类的东西仍然可以自由地做他们关于合并、重新排序的事情（你对 fio 的 sync=1 的使用是停止重新排序的原因）等等 O_DIRECT I/O.

此外，如果您正在对文件系统中的文件执行 I/O，那么 .

是合法的

请参阅 https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt 中 nomerges 的不同参数，了解如何教调度程序避免 merging/rearranging 但请注意，您无法控制请求的拆分太过分大.

综上所述，看起来很多 I/O 合并（由 wrqm/s 给出）似乎都发生在您的场景，但仍然有些奇怪。 avgrq-sz 是 9.36，因为该值在 512 字节扇区中，我们得到 4792.32 字节作为提交到磁盘的平均请求大小。该值非常接近 fio 使用的 4096 字节块大小。由于您不能对磁盘执行 non-sector 大小 I/O 并假设磁盘的块大小为 512 字节，这表明合并 4KBytes + 512 字节（我假设其余的是噪音）但因为它是平均可能有一些东西做大（r）I/O，同时 fio 做小 I/O，而平均值刚好达到 in-between。因为 I/O 发生在文件系统中的文件上，这可能是因为文件系统元数据正在更新...

为什么写 O_DIRECT 和 O_SYNC 仍然导致 io 合并？

Why writes with O_DIRECT and O_SYNC still causing io merge?

linux

io

iostat