印度机房用 dd 测盘速，缓存把 200MB/s 写成了 2GB/s

印度西海岸那台备份机，Ubuntu 22.04，两块 4TB SATA 盘做 RAID1，文件系统 ext4。业务侧反馈备份窗口从 40 分钟涨到 3 小时，我先怀疑是网络，排除后转向磁盘。用 dd 随手一测，写速度 2.1GB/s，读 3.4GB/s，看着比本地 NVMe 还快，明显不对。

我先确认块设备本身：

lsblk -o NAME,ROTA,SCHED,SIZE
cat /sys/block/sda/queue/rotational

rotational 是 1，机械盘。再用 dd 加 oflag=direct 绕开页缓存：

dd if=/dev/zero of=/data/testfile bs=1M count=2048 oflag=direct status=progress
dd if=/data/testfile of=/dev/null bs=1M iflag=direct status=progress

写降到 118MB/s，读 132MB/s，这才像话。之前那个 2GB/s 是数据全进了内存，dd 写完就返回，脏页还没落盘。

为什么加 oflag=direct 就准：它让读写直接对块设备发起，不经过 page cache，测的是盘和 RAID 控制器的真实吞吐。代价是丢掉了合并写和预读，顺序大块场景下会比真实业务略低；反过来，不带 direct 的数字只能说明内存带宽。

真正踩的坑在后面。用 direct 测出来 118MB/s，但业务备份还是慢。iostat -x 1 看 %util 接近 100、aqu-sz 很高，await 却只有十几毫秒。问题不在盘，在 ext4 的 journal：备份是大量小文件加删除，元数据提交把队列压满了。后来把备份改成先 tar 成单个大文件再写，窗口回到 50 分钟左右。

边界条件也说清楚：oflag=direct 在 tmpfs、overlayfs 上可能直接报错，容器里跑要先确认挂载类型；bs=1M count=2048 只测顺序，随机 IOPS 得用 fio，别拿 dd 的数字去判断数据库盘。还有一次我在已经挂载的盘上写测试文件，把 RAID1 的剩余空间写到 95%，差点影响线上，后来固定用 /data/ddtest 并由脚本先检查 df。

你们在印度这类 SATA 盘机器上，测盘速时是坚持 direct，还是先用 fio 跑一组随机读写再下结论？