用 dd 测真实写速度需加 oflag=direct 绕过页缓存，命令示例：time dd if=/dev/zero of=/mnt/testfile bs=1M count=2048 oflag=direct；避免写入内存盘、小块测试及未清理缓存等误操作。
怎么用 dd 测真实写速度，而不是缓存假象
直接测出的“写速”经常虚高，因为 Linux 默认把数据先扔进页缓存（page cache），dd 报的其实是内存拷贝速度。要看到磁盘真实吞吐，必须绕过缓存。
- 加
oflag=direct：强制直写磁盘，跳过内核缓冲区（推荐首选） - 或用
conv=fdatasync/oflag=dsync：让每次写都等数据真正落盘再返回（更严格，但更慢，适合测延迟敏感场景） - 别只跑一次：缓存干扰、预热、文件系统元数据开销都会影响结果，建议至少重复 2–3 次取稳定值
- 测试文件路径选目标盘：比如想测
/dev/sdb，就写到挂载在它上面的目录（如/mnt/data/test），别写在/tmp（常是 tmpfs 内存盘）
dd 写速命令怎么写才靠谱
下面这条是兼顾可读性、真实性、通用性的最小可靠命令：
time dd if=/dev/zero of=/mnt/testfile bs=1M count=2048 oflag=direct
-
if=/dev/zero：不产生 IO，纯测写通路 -
bs=1M：块大小设大些（1M 是 SSD/HDD 都较友好的起点），太小（如 4k）会放大元数据和调度开销 -
count=2048→ 写 2GB：足够长以摊平启动抖动，又不会耗太久 -
oflag=direct：关键！没它基本白测 - 别用
conv=notrunc或seek来“追加”，那会引入 seek 时间，不再是纯顺序写
为什么 dd 测出来的数字和 hdparm -t 差很多
不是谁错了，是测的根本不是一回事：
-
hdparm -t测的是「缓存读」+「物理盘读」两段：前者快得离谱（如 3GB/s），后者才是盘的真实读带宽（常 100–500MB/s） -
dd if=/dev/zero of=... oflag=direct测的是「应用层发起→文件系统→驱动→磁盘」全链路顺序写能力 -
dd if=testfile of=/dev/null iflag=direct才对应hdparm的物理读部分；而iflag=direct同样不能少，否则读的是 page cache - SSD 上
dd可能比hdparm物理读还快——说明文件系统或驱动做了优化（如合并、预取），这反而是好现象
常见误操作和对应现象
这些坑踩一个，结果就不可信：
- 漏掉
oflag=direct→ 报出 2GB/s，实际硬盘只有 300MB/s：那是内存速度，不是磁盘 - 写到
/tmp（默认是内存 tmpfs）→ 速度爆表且毫无意义 - 用
bs=4k count=1000000测“IOPS” →dd不是随机 IO 工具，这样只是大量小顺序写，结果偏高且不反映真实随机负载 - 测试中途有其他进程刷盘（如日志、备份）→ 速度跳变、波动大，应清空后台任务或在低峰期测
- 没删测试文件就重跑 → 文件系统可能复用旧 block，跳过擦除（尤其 SSD），导致第二次更快
真实磁盘 IO 不是单个数字能概括的，dd 只能告诉你“大块顺序写有多快”。如果业务是数据库或小文件服务，下一步该上 fio ——但那是另一个问题了。
