Linux bonnie++ / iozone 的文件系统基准测试对比

bonnie++适合测小文件吞吐与元数据操作性能，如文件服务器、邮件归档、日志轮转；不适合测数据库或高并发随机i/o，因其不支持队列深度控制、异步i/o定制及读写混合比例配置。

bonnie++ 适合测什么，什么时候别硬上

bonnie++ 的核心价值是快速评估「小文件吞吐 + 元数据操作」能力，比如文件服务器、邮件归档、日志轮转这类场景。它默认会大量创建/删除/重命名小文件，并混合测试顺序读写和随机读写，结果里 Sequential Output 和 Create（每秒新建文件数）这两项最能反映真实业务压力。

但它不适合测数据库或高并发随机 I/O 场景：不支持指定队列深度（io_depth），不能控制异步 I/O 行为，也没有像 fio 那样可定义的 read/write 混合比例。如果你用 bonnie++ -s 2g -u root 测一块 NVMe 盘，看到 Random Seek 才 1200 IOPS，别急着骂盘——它压根没走真正的 async I/O 路径，只是用多线程模拟，结果偏保守。

• 别在生产库前用 bonnie++ 做容量规划依据，它的随机读写结果跟 mysqlslap 或真实 workload 差距较大
• 测试目录必须有足够空间（至少 2× -s 参数值），否则中途报 write: No space left on device 不提示具体哪个子测试失败
• -n 参数控制小文件测试数量，默认只跑 100 个，想看元数据瓶颈得手动加到 -n 1000 以上，否则 Create 和 delete 指标没意义

iozone 的关键参数怎么配才不白跑

iozone 强在覆盖全链路文件操作：从 fread/fwrite 到 mmap、aio_read，甚至支持 POSIX 线程并发和集群文件系统打点。但默认 iozone -a 是陷阱——它用 64KB 块大小扫一遍所有模式，耗时长、结果杂，且对现代 SSD 的 4K 对齐不敏感。

真正有用的组合是锁定模式 + 显式绕过缓存：-i 0（写）、-i 1（读）、-I（强制 O_SYNC）、-f（指定测试文件路径）。尤其 -I 必须加，否则测出来的是 page cache 性能，不是磁盘真实延迟。

• 测试大文件顺序吞吐，用 iozone -s 4g -r 1m -i 0 -i 1 -I -f /mnt/test/iozone.dat；-r 1m 让块大小匹配 RAID 条带或 SSD 页大小
• 测随机读性能（类似数据库 buffer pool miss），改用 -i 2 并配合 -+n（禁用预读）：iozone -s 2g -r 4k -i 2 -+n -I -f /mnt/test/rand.dat
• 导出 excel 用 -Rb out.xls，但注意：如果系统没装 perl 的 Spreadsheet::WriteExcel 模块，会静默失败，只生成空文件——先跑 perl -MSpreadsheet::WriteExcel -e 'print "okn"' 确认

两者输出里最容易误读的三行指标

bonnie++ 报告末尾的 ------Sequential Output------ 下面有三行数字，很多人直接抄最大值当“写入速度”：第一行是 Per char（字符模式，基本不用），第二行 Block（缓冲写，含 cache），第三行 Rewrite（带 fsync 的重写，才是真写盘速度）。同理，iozone 的 re-write 行比 write 行低 30%~50%，不是工具问题，是 fsync() 强制刷盘的真实代价。

• bonnie++ 的 Random Seek 单位是 seeks/sec，不是 IOPS；它测的是单线程 seek() + read(1) 组合，跟存储的 4K 随机读 IOPS 不等价
• iozone 的 random read 和 pread 数值常差 2× 以上——前者用 lseek()+read()，后者用 pread() 系统调用，内核路径不同，对某些文件系统（如 XFS）影响显著
• 两者都默认用 tmpfs 或普通目录做测试载体，若目标是测 ext4 vs XFS，务必清空 page cache（echo 3 > /proc/sys/vm/drop_caches）并卸载重挂文件系统，否则残留元数据缓存会让结果失真

别跳过的底层前提：文件系统挂载选项和硬件对齐

再准的工具，测的也是当前配置下的表现。bonnie++ 和 iozone 都依赖 open()/write() 等系统调用，而这些调用的行为直接受挂载参数影响。比如 ext4 默认 data=ordered，写日志但不 sync 数据块；XFS 默认 allocsize=64k，影响小文件分配效率。不显式指定 -o nobarrier 或 -o journal=async，测出来的就不是纯磁盘能力，而是日志策略+磁盘的耦合结果。

• SSD 测试前确认分区对齐：cat /sys/block/nvme0n1/nvme0n1p1/start 应该是 2048（1MB 对齐），否则 iozone -r 4k 实际触发的是跨页读写，性能腰斩
• 使用 -I（iozone）或 -b（bonnie++ 的 barrier 模式）时，确保磁盘支持 flush 命令：hdparm -I /dev/nvme0n1 | grep -i flush，不支持的 SATA 盘会退化成全盘等待
• 如果测试 NFS 或 CephFS，bonnie++ 的 Create 和 Delete 会暴增 latency，此时应关掉 -n 改用 -d（仅测文件内容），否则 90% 时间花在 mkdir rpc 上，跟存储本身无关

实际跑下来，多数人卡在「为什么两次测试结果差一倍」——大概率是第一次没清缓存，第二次用了不同块大小，或者忘了 -I。工具只是镜子，照出的是配置、硬件、内核和文件系统的共同作用。