fio测磁盘I/O必须加--direct=1和--sync=1或--fsync，否则结果反映的是缓存速度而非磁盘真实性能；默认参数下write()走page cache，小文件随机写可能未落盘。
直接上结论：用 fio 测 Linux 磁盘 I/O，别只跑默认参数，否则测出来的是缓存速度、不是磁盘真实吞吐，结果完全不可信。
为什么 fio 默认测试根本不能反映磁盘性能
默认不加任何绕过缓存的选项时，fio 读写全部走 page cache，尤其小文件随机写，可能压根没落盘——你看到的 500MB/s 是内存带宽，不是 SSD 的 400MB/s 顺序写。关键在于 Linux 内核会把 write() 缓存起来，直到 fsync() 或脏页回写触发才真正写入设备。
- 必须加
--direct=1：绕过 page cache，让 I/O 直达块设备 - 必须加
--sync=1或搭配--fsync=xx：强制每次写都等落盘完成（适用于测延迟敏感场景） - 避免用
--name=test这类无意义名字，改用能体现负载特征的名，比如--name=randwrite-4k-qd32
fio 常见测试模式对应的实际场景
不同参数组合不是为了炫技，而是模拟真实业务压力源。数据库、日志、备份、虚拟机镜像，I/O 模式天差地别。
-
--rw=randread --bs=4k --iodepth=1：模拟 OLTP 数据库点查，关注单线程 4K 随机读 IOPS 和延迟 -
--rw=write --bs=1M --iodepth=64：模拟日志刷盘或备份写入，看大块顺序写吞吐（MB/s），此时--direct=1必须开，否则被缓存掩盖瓶颈 -
--rw=randwrite --bs=4k --iodepth=32 --numjobs=4：模拟多实例 MySQL 写入，--numjobs控制并发进程数，--iodepth控制每个进程队列深度，两者共同决定总并发请求数
几个极易踩的坑和验证方法
跑完 fio 报告里一堆数字，但你得知道哪些值真有用、哪些是干扰项。
- 别只看
bw（带宽），先盯iops和lat (avg)：4K 随机读写，IOPS 和平均延迟比 MB/s 更有参考价值 - 检查
ioengine是否为libaio：默认sync引擎是阻塞的，libaio+--direct=1才能测出 NVMe/SSD 的高并发能力；用fio --engines=list查本机支持的引擎 - 确认测试文件不在 LVM / RAID / LUKS 层之上却没意识到：这些层会引入额外延迟，
fio测的是“整个栈”，不是裸盘；如需定位磁盘本身，应在物理分区（如/dev/nvme0n1p1）上测，而非逻辑卷（如/dev/mapper/vg-lv） - 跑之前清空缓存：
echo 3 > /proc/sys/vm/drop_caches，并确保测试文件大小远大于可用内存（例如 20G 文件测 64G 内存机器），否则部分数据仍被缓存命中
一个可直接复制粘贴的基准测试命令
这不是“万能模板”，而是覆盖多数服务器磁盘验收场景的最小可靠组合：
fio --filename=/mnt/testfile --rw=randwrite --bs=4k --size=20G --ioengine=libaio --direct=1 --iodepth=32 --numjobs=4 --runtime=60 --time_based --group_reporting --name=randwrite-4k-qd32-j4
说明：--time_based 和 --runtime=60 确保固定运行 60 秒，不受文件大小影响；--group_reporting 合并所有 job 结果，避免输出几十行重复指标；测完立刻看 IOPS 和 lat (avg) 行，其余可忽略。
真正难的不是跑通 fio，而是理解你测的那个数字——到底代表应用哪一部分的瓶颈。同一块盘，randread 和 read 差 10 倍很正常，关键是你在替哪个服务做决策。
