dd测出的是单线程大块顺序I/O极限值，非业务真实性能；加oflag=direct绕过page cache测真实磁盘写速，读前须sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"清缓存，否则结果虚高；bs与count需合理搭配，小IO应换fio测试。
dd 测出来的数字，不能直接当业务性能看——它只反映单线程、大块、顺序 I/O 的极限值，但能快速揪出硬件级瓶颈或配置问题。
为什么写入测试必须加 oflag=direct
不加这个参数，dd if=/dev/zero of=testfile bs=1G count=4 实际测的是内存带宽 + 文件系统缓存能力，不是磁盘真实写速。内核会把数据先塞进 page cache，dd 返回完成时，数据可能还在内存里没落盘。
-
oflag=direct强制走 O_DIRECT 路径，绕过页缓存，让数据直通磁盘（或设备驱动） - 目标路径必须是真实挂载的磁盘分区（如
/mnt/data），不能是/tmp（可能是 tmpfs）或已满空间 - 若提示
Invalid argument，说明文件系统不支持 direct I/O（如某些 FUSE 类型），此时去掉该 flag，但结果要打折扣理解 - 搭配
conv=fdatasync或oflag=sync可确保 write() 返回前数据已刷入磁盘介质，尤其对带写缓存的 SATA SSD 或 RAID 卡更关键
读取测试前一定要清缓存
刚写完就立刻读，dd if=testfile of=/dev/null bs=1G iflag=direct 很可能从 DRAM 缓存或磁盘自身缓存读，结果虚高 2–5 倍。
- 清缓存命令必须用 root 权限：
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" -
echo 3清的是 page cache + dentries + inodes，比echo 1更彻底 - 清完再跑读测试；如果还怀疑，可用
hdparm -t /dev/sdb对比：若dd结果远高于hdparm，基本确认缓存没清干净 - 注意：
iflag=direct在部分 NFS 或 CephFS 上会失败，去掉后测得的是“含缓存读速”，需明确标注
bs 和 count 怎么选才靠谱
bs 不是越大越好，count 太小会让结果受瞬时干扰严重——一次 10MB 写入，可能被日志刷盘、中断抢占拖慢；一次 1GB 写入更能压出连续吞吐。
- 机械盘 / 普通 SATA SSD：用
bs=4M或bs=8M，count=100（即 400–800MB），平衡稳定性与耗时 - NVMe / 高性能 SSD：可试
bs=64M或bs=128M，有些设备在大块下才能跑满 PCIe 带宽 - 绝对避免
bs=512或bs=4k来“模拟数据库”——那已经不是dd的适用场景，该换fio - 每次测试至少跑 3 轮，取中间值；别信
status=progress显示的实时速率，只看最后输出的X bytes copied, Y s, Z GB/s
别拿 dd 当全盘性能报告用
它不测随机 I/O、不报延迟、不模拟多队列并发、也不区分读写混合压力——这些恰恰是数据库、K8s 存储卷、虚拟机镜像加载的真实瓶颈点。
- 4K 随机读写、IOPS、99% 延迟？用
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --iodepth=32 --runtime=60 - 裸设备顺序吞吐对比？用
hdparm -tT /dev/nvme0n1，它绕过文件系统，更接近物理层极限 - 想看实时 IO 分布？
iostat -x 1比dd输出更有诊断价值 -
dd唯一不可替代的价值：三分钟内验证“这盘是不是真坏了”或者“挂载选项有没有禁掉 barrier”
