为什么使用直接标志的dd比dsync慢得多

Question

我正在尝试使用dd测试我的ceph文件系统的性能。在测试过程中，我发现了一些令人困惑的事情，即使用oflag=dsync或conv=fdatasync/fsync的dd比使用oflag=direct的dd快约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

- ustcyue

---

你是否曾经成功收集到 iostat 输出？ - Anon

Answer 1

使用oflag=dsync或conv=fdatasync/fsync的dd命令速度约快10倍，而使用oflag=direct的dd命令则不然。

conv=fdatasync/conv=fsync仍意味着I/O最初会被排队到内核缓存中，并根据内核的需要将其写入磁盘。这给了内核一个很大的机会来合并I/O、创建尚未写入磁盘的I/O的并行提交，并将I/O提交到内核与磁盘的接受（在缓冲允许的范围内）分离。只有当dd完成发送所有数据时，它才必须等待任何仍在缓存中的数据刷新到磁盘上（使用fsync时包括任何元数据）。

oflag=dsync仍允许利用内核缓存-只是在每次提交后会导致刷新+等待完成。由于你只发送一个巨大的写操作，这将使你进入几乎与上面使用conv=fdatasync相同的情况。

当您指定oflag=odirect时，您是在说“相信我的所有参数都是合理的，并尽可能关闭内核缓冲区”。在您的情况下，使用如此巨大的bs是不合理的，因为您的“磁盘”的最大传输块大小（更不用说最佳大小）几乎肯定更小。您可能会触发分割，但由于O_DIRECT的内存需求，分割点可能会导致比上述情况更小的I / O。

虽然很难确定确切的情况，但我们真正需要看到I/O离开内核底部的方式（例如通过比较运行期间的iostat输出），以更好地了解情况。

简而言之，也许使用odirect会导致更小的I/O离开内核，从而在您的情况下导致更差的性能？

- Anon

---

这些选项中哪一个最接近于例如cp的写入？我想使用dd的速度输出来测量写入速度。 - jaaq