dd测顺序吞吐上限，fio测真实业务随机性能；dd适合快速验证链路与大块带宽，fio支持并发、随机、混合负载及iops/延迟等多维指标。

Linux磁盘性能测试不能只看一个数字——dd 测的是大块顺序吞吐的“天花板”，fio 测的是真实业务下随机访问的“实际表现”。两者目标不同、方法不同、结果也不能直接比较。

dd 测试：专注顺序读写带宽

dd 适合快速验证磁盘链路是否通畅、文件系统挂载是否正常、以及大块连续 I/O 的理论上限。它不模拟并发、不统计延迟、也不支持随机模式，但胜在简单可靠。

• 写入测试：用 dd if=/dev/zero of=/mnt/testfile bs=1M count=2048 conv=fdatasync，其中 fdatasync 确保数据真正落盘，避免缓存干扰
• 读取测试：先执行 sync && echo 3 > /proc/sys/vm/drop_caches 清空页缓存，再运行 dd if=/mnt/testfile of=/dev/null bs=1M iflag=direct，iflag=direct 强制绕过缓存读物理介质
• 注意块大小：bs=4k 得到的是小 IO 吞吐（单位 MB/s）和隐含 IOPS，bs=1M 才能逼近视频、备份类场景的带宽极限；同一块盘，两者结果可能差 5 倍以上
• 别信单次结果：count 太小（如 count=1）或未清缓存，会导致数值虚高或剧烈波动；建议至少写入 512MB 以上，并多次测试取稳定值

fio 测试：覆盖真实业务负载

fio 是专业级 IO 压力工具，能精准建模数据库、虚拟机、日志服务等典型场景。它输出 IOPS、带宽、平均延迟、p95/p99 延迟等关键指标，是评估存储能否承载业务的核心手段。

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• 必须加 direct=1：否则测的是内存+缓存性能，不是磁盘本身；所有结果都应基于 direct=1 运行
• 按业务选参数：
  • OLTP 类（如 MySQL）：rw=randwrite 或 randread，bs=4k，iodeth=32（SSD）或 8（HDD）
  • 日志类（如 Kafka）：rw=write，bs=128k–1M，关注持续吞吐与稳定性
  • 混合负载：用 rw=randrw,rwmixread=70 模拟读多写少的缓存型服务
• 延迟比 IOPS 更关键：尤其对数据库，p99 延迟超过 20ms 就可能引发超时；fio 默认输出 clat（completion latency）的百分位值，务必检查
• 文件还是裸设备：测试文件系统性能，就写路径（如 /mnt/data/test.fio）；测试底层磁盘能力，需卸载后直写 /dev/sdb，但操作风险高，慎用

什么时候该用哪个工具

不必纠结“哪个更好”，而要看你想回答什么问题：

• 新盘上线，想确认能不能达到标称 500MB/s？→ 用 dd 测顺序写，bs=1M + conv=fdatasync
• MySQL 响应变慢，怀疑是磁盘随机写瓶颈？→ 用 fio 跑 randwrite,bs=4k,iodepth=32,direct=1，重点看 p99 延迟
• 对比两套存储方案，谁更适合跑 Elasticsearch？→ fio 配置 randrw,rwmixwrite=30,bs=8k,iodepth=16，比对 IOPS 和延迟抖动
• 运维巡检，快速筛查磁盘是否掉速或异常？→ dd 写一次 + 读一次，耗时不到一分钟，有明显下降就需深入排查

几个容易踩的坑

很多“测出来很慢”的报告，其实不是磁盘问题，而是测试方式不对：

• 没清缓存就测读：刚写完马上读，结果反映的是 DRAM 缓存速度，不是磁盘
• 混用 conv 和 oflag/iflag：比如同时写 conv=fdatasync 和 oflag=direct，部分内核版本会报错或行为异常
• SSD 测试没关写缓存：SATA SSD 或 RAID 卡常带 DRAM 缓存，不加 conv=fdatasync 或 oflag=dsync，写速虚高数倍
• fio 没设 iodepth：默认 iodepth=1，相当于单线程串行压测，完全无法体现 SSD 并发优势