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 倍很正常，关键是你在替哪个服务做决策。