ust*_*yue 1 linux filesystems ceph
我试图使用 dd 来测试我的 ceph 文件系统的性能。在测试过程中，我发现了一些令人困惑的事情，即 dd 和 oflag=dsync 或 conv=fdatasync/fsync 比 dd 和 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
使用 oflag=dsync 或 conv=fdatasync/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因为您的“磁盘”的最大传输块大小（更不用说最佳大小）几乎肯定会更小。您可能会触发拆分，但由于O_DIRECT拆分点的内存要求可能会导致比上述情况更小的 I/O。
虽然很难确定发生了什么。实际上，我们需要查看 I/O 如何离开内核底部（例如，通过比较iostat运行期间的输出）以更好地了解正在发生的事情。
TLDR；也许使用odirect会导致较小的 I/O 离开内核，从而导致您的场景中的性能更差？