dd测写速数值虚高因默认仅写入page cache而未强制落盘，需用conv=fdatasync或oflag=dsync确保数据同步到磁盘，否则测得的是内存带宽而非真实磁盘性能。
dd 测试写速度时为什么数值虚高？
因为默认不强制刷盘，dd 把数据写进 page cache 就算完成，实际落盘被延后。你看到的“800MB/s”可能是内存带宽，不是磁盘真实写入能力。
必须加同步控制参数，否则结果完全不可比。常见错误是只加 sync 命令在分号后面，比如：dd if=/dev/zero of=test bs=1M count=128; sync——这根本没用，sync 执行时 dd 早结束了，测的还是缓存速度。
-
conv=fdatasync：整个写操作完成后执行一次fdatasync()，强制把本次dd写的数据刷到磁盘，最常用也最贴近真实场景 -
oflag=dsync：每次写一块都调用O_DSYNC，绕过缓存直写，性能最低但最严苛，适合模拟小事务写入（如数据库日志） - 别用
oflag=direct单独测写——它跳过 page cache，但不保证元数据落盘，dd可能因 ext4 日志机制仍产生额外开销，结果不稳定
dd 测试读速度怎么避免缓存干扰？
读测试更容易被缓存污染。如果刚写完就立刻读，系统大概率从 page cache 返回数据，测出来是内存速度而非磁盘。
正确做法是先清空缓存，再读；且必须用 iflag=direct 强制物理读。命令示例：
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' time dd if=test of=/dev/null bs=1M iflag=direct
注意：drop_caches 需要 root 权限，普通用户会失败；iflag=direct 是关键，没它就白清。
- 不要用
of=/dev/null后再加sync——读操作本身不涉及写缓存，sync对读无意义 - 文件
test必须已存在且足够大（建议 ≥2GB），否则可能被全部载入缓存，清缓存也无效 - SSD 上多次读结果波动大，建议至少跑 3 次取中位数
bs 块大小怎么选才反映真实性能？
块大小直接影响 I/O 调度、队列深度和底层设备响应方式。盲目用 bs=1M 可能掩盖随机 I/O 瓶颈，而 bs=4k 又可能受 CPU 和中断开销主导。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
按用途选：
- 测顺序吞吐（如备份、大文件传输）：用
bs=1M或bs=4M - 测数据库类负载（如 MySQL redo log）：用
bs=4k+oflag=dsync - 测混合负载或找瓶颈点：对比
bs=4k、bs=64k、bs=1M三组，看性能拐点
注意：count 要够大（例如 count=10000 对应 4k 块就是 40MB），否则测试时间太短，系统调度噪声占比过高。
fio 比 dd 更准，但什么情况下必须用 dd？
当你只有基础系统、无法安装额外工具，或需要快速验证某块盘是否明显异常时，dd 是唯一选择。它轻量、无依赖、输出直观。
但 dd 本质是单线程顺序流，没法模拟多队列、随机读写、混合读写比、IO 深度等真实负载。比如：
-
dd测不出 NVMe 盘在iodepth=32下的真实 IOPS -
dd无法区分 4k 随机读延迟是 100μs 还是 5ms -
dd的 “读写同时” 实际是先读后写，不是并发
真正做容量规划或故障复现，必须切到 fio；但日常巡检或应急判断，dd if=/dev/zero of=test bs=1M count=1024 conv=fdatasync 一行足够。
