Linux系统磁盘性能测试：避开dd命令的那些“坑”
说到在Linux下快速测试磁盘性能，dd命令绝对是很多人的第一反应。它简单、直接，几乎无处不在。但你是否也遇到过这样的困惑：明明测出来写入速度高达800MB/s，实际拷贝大文件时却慢如蜗牛？问题很可能就出在测试方法上——你测到的，或许只是内存的速度。
dd 测试写速度时为什么数值虚高？
核心原因在于缓存。默认情况下，dd命令将数据写入操作系统的页面缓存（page cache）后就会报告完成，至于数据何时真正落到物理磁盘上，那是后台异步刷盘的事。这就会导致一个典型现象：你看到的“超高速度”，其实是内存带宽的体现，而非磁盘真实的持续写入能力。
因此，要让测试结果有意义，必须加上同步控制参数。这里有个常见的误区：有些人会在dd命令结束后，手动执行一个sync命令，比如dd if=/dev/zero of=test bs=1M count=128; sync。这其实是无效的，因为当sync开始执行时，dd进程早已结束，它同步的是系统全局缓存，无法准确度量本次dd写入的数据，结果依然不可靠。
正确的姿势是使用dd自带的参数来控制刷盘时机：
conv=fdatasync：这是最常用也最推荐的方式。它会在整个写操作完成后，执行一次fdatasync()系统调用，强制将本次dd写入的所有数据（不包括元数据，如修改时间）刷入磁盘。这个场景最贴近大多数应用（如文件下载）的实际行为。oflag=dsync：这是最严苛的模式。它要求每次写入一个数据块（由bs指定）后，都立即调用O_DSYNC同步到磁盘。这种方式会严重降低吞吐量，但非常适合模拟数据库事务日志（如redo log）这类对每次写入都有持久化要求的场景。- 慎用
oflag=direct：单独使用它来测试写入并不理想。它虽然跳过了页面缓存，直接进行I/O，但并不能保证元数据同步。在某些文件系统（如ext4）上，由于日志机制的存在，仍然会产生额外的开销，导致测试结果不稳定，缺乏可比性。
简单来说，dd测试写速度数值虚高，是因为默认仅写入page cache而未强制落盘。必须使用conv=fdatasync或oflag=dsync来确保数据同步到磁盘，否则测得的只是内存带宽。
dd 测试读速度怎么避免缓存干扰？
读测试比写测试更容易“踩坑”。如果你刚刚写完一个测试文件，紧接着就去读它，系统极大概率会直接从页面缓存中返回数据，这测出来的速度，自然又是内存的性能。
正确的流程分两步：首先清空缓存，然后使用直接I/O方式进行读取。一个标准的命令示例如下：
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' time dd if=test of=/dev/null bs=1M iflag=direct
这里有三个关键点需要注意：
- 清缓存需要权限：向
/proc/sys/vm/drop_caches写入`3`（表示清空页缓存、目录项和inode缓存）需要root权限，普通用户执行会失败。 iflag=direct是关键：这个参数告诉dd绕过缓冲区缓存，直接从磁盘读取。如果没有它，即使清了缓存，后续的读操作也可能被再次缓存，导致前功尽弃。- 文件要足够大：测试文件（本例中的
test）建议不小于2GB，以确保其无法被完全装入内存缓存。否则，清缓存的操作可能效果有限。
另外，对于SSD这类设备，多次读取的结果可能会有波动，建议至少测试3次并取中位数，以获得更具代表性的数据。
bs 块大小怎么选才反映真实性能？
块大小（bs参数）的选择绝非随意，它直接决定了I/O请求的粒度，影响着操作系统的调度策略、设备队列深度以及底层硬件的响应模式。
盲目选择会带来误导：使用过大的块（如bs=1M）测试顺序吞吐固然好看，但可能完全掩盖了磁盘在处理小文件随机I/O时的性能瓶颈；而使用过小的块（如bs=4k）则可能让测试结果被CPU中断处理、系统调用开销所主导，无法真实反映磁盘极限。
如何选择？关键在于匹配你的实际应用场景：
- 测试顺序吞吐量：例如备份、大文件传输。适合使用较大的块，如
bs=1M或bs=4M。 - 测试数据库类负载：例如MySQL的redo log写入。这需要模拟同步、小块的写入，应使用
bs=4k配合oflag=dsync。 - 探索性能拐点：如果不确定应用模式，可以做一个对比测试。分别用
bs=4k、bs=64k、bs=1M进行测试，观察性能曲线的变化，找到吞吐量和延迟的平衡点。
还有一个细节：count参数要足够大，以确保总的测试数据量能让测试持续数秒以上。例如，当bs=4k时，count=10000才对应40MB数据。测试时间太短，系统本身的调度噪声占比会过高，结果就不够准确。
fio 比 dd 更准，但什么情况下必须用 dd？
必须承认，专业的磁盘性能基准测试工具是fio（Flexible I/O Tester）。它能精确模拟多线程、随机读写、混合读写比例、不同I/O队列深度等复杂负载，这是dd望尘莫及的。
dd本质上是一个单线程的顺序流工具，其局限性很明显：
- 它无法压测出NVMe SSD在高队列深度（如
iodepth=32）下的真实IOPS。 - 它无法精确衡量4KB随机读写的延迟（是100微秒还是5毫秒？）。
- 它所谓的“读写同时”测试（用
if和of指定不同文件），实际上是先读后写的串行操作，并非真正的并发。
那么，dd的价值何在？恰恰在于它的“简陋”。当你身处一个最小化安装的基础系统，没有权限或无法安装额外软件时；当你需要快速验证一块磁盘是否能够正常读写、性能是否存在断崖式下跌时，dd就是那个最可靠、触手可及的“瑞士军刀”。一行命令：dd if=/dev/zero of=test bs=1M count=1024 conv=fdatasync，就能给你一个快速的、定性的答案。
所以，结论很清晰：进行严肃的容量规划、性能评估或故障复现，请务必使用fio。但对于日常的系统巡检、应急排查或是快速验证，dd在正确使用的前提下，依然是一个不可或缺的得力工具。关键在于，你得知道它的“坑”在哪，并且懂得如何避开。
