为什么带有直接标志的dd比dsync慢得多

Question

我试图使用 dd 来测试我的 ceph 文件系统的性能。在测试过程中，我发现了一些令人困惑的地方，即 dd with oflag=dsync 或 conv=f​​datasync/fsync 比 dd with oflag=direct 快 10 倍左右。

我的网络是 2*10Gb

/mnt/testceph# dd if=/dev/zero of=/mnt/testceph/test1  bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 23.1742 s, 46.3 MB/s


/mnt/testceph# dd if=/dev/zero of=/mnt/testceph/test1  bs=1G count=1 conv=fdatasync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.22468 s, 483 MB/s

Answer 1

使用 oflag=dsync 或 conv=f​​datasync/fsync 的 dd 比使用 oflag=direct 的 dd 快 10 倍左右

conv=fdatasync / conv=fsync 仍然意味着 I/O 最初排队到内核缓存并在内核认为合适的情况下转移到磁盘。这为内核提供了合并 I/O、从尚未降级的 I/O 创建并行提交的大好机会，并且通常将向内核提交的 I/O 与磁盘的 I/O 接受分离（在某种程度上缓冲将允许）。只有当dd 完成发送所有数据时，它才必须等待仍然仅在缓存中的任何内容被刷新到磁盘（以及包含任何元数据的fsync）。

oflag=dsync 仍然允许使用内核缓冲——它只是在每次提交后导致刷新+等待完成。由于您只发送一个巨大的写入，这将使您进入与上述conv=fdatasync 相同的场景。

当您指定oflag=odirect 时，您是在说“相信我的所有参数都是合理的，并尽可能多地关闭内核缓冲”。在您的情况下，bs 与odirect 一样大是荒谬的，因为您的“磁盘”的最大传输块大小（更不用说最佳大小）几乎肯定会更小。您可能会触发拆分，但due to memory requirements on O_DIRECT the splitting points may lead to smaller I/Os 比上述情况。

虽然很难确定发生了什么。实际上，我们需要查看 I/O 是如何离开内核底部的（例如，通过在运行期间比较 iostat 输出）以更好地了解发生了什么。

TLDR;也许使用 odirect 会导致更小的 I/O 离开内核，从而导致您的场景中的性能变差？