filebench：给文件系统建「真实负载模型」

更新时间：2026-09-19。fio 擅长对块设备发标准化的顺序/随机 IO；而 filebench 在文件系统之上通过可配置的工作负载模型（WML）模拟「文件服务器、邮件服务器、Web、OLTP」等真实访问模式，更能体现元数据操作、目录结构、缓存和挂载选项的影响。

一、内置 personality（快速跑）

# 查看自带工作负载模型
ls /usr/share/filebench/workloads/
filebench -f /usr/share/filebench/workloads/fileserver.f
filebench -f /usr/share/filebench/workloads/webserver.f
filebench -f /usr/share/filebench/workloads/oltp.f
filebench -f /usr/share/filebench/workloads/varmail.f

模型	模拟	典型 IO 特征
fileserver	文件服务器	大量 create/delete/stat、混合读写、目录遍历
webserver	静态 Web	多为 open+read、日志 append 写
varmail	邮件存储	大量小文件 fsync、create/unlink（强元数据/日志压力）
oltp	数据库	稀疏读写、fsync/O_DIRECT，考验 WAL/日志
videoserver	流媒体	大文件顺序读

模型内有 set $dir=/mnt/test 之类变量，跑前必须指向目标文件系统，否则压的是默认/根目录。

二、工作负载模型语言（WML）结构

自定义模型由四部分组成：

define fileset name=data,path=$dir,entries=10000,size=16k,prealloc
# fileset：文件集（数量、大小、目录宽度、是否预分配）

define process name=svc,instances=4 {
  thread name=t1,instances=8 {
    flowop openfile name=op1,filesetname=data
    flowop readwholefile name=op2,filesetname=data,iosize=4k
    flowop writewholefile name=op3,filesetname=data,iosize=4k,fd=1
    flowop closefile name=op4,fd=1
    flowop fsync name=op5
    flowop createfile name=op6,filesetname=data
    flowop deletefile name=op7,filesetname=data
  }
}

run 60        # 运行 60 秒

• fileset：决定文件数量、大小分布、目录层级（entries/size/dirwidth），直接影响 inode/目录项缓存命中率。
• process/thread：并发度，模拟多客户端。
• flowop：操作序列与比例（open/read/write/fsync/create/delete/stat…），权重用 flowop ... ,iters= 组织。
• run：时长。fsync 频率是区分「邮件/DB 类持久负载」和「普通读写」的关键。

三、执行流程与输出

sudo modprobe loop    # 某些发行版需要
sudo filebench -c myload.f        # -c 先分配/预创建文件集
sudo filebench -f myload.f        # 正式运行

IO Summary:
  ops:    152340   ops/s: 2539.0   Mb/s:  10.2
  read/write 比例、open/close、getattr、fsync 各项计数
  latency 平均/最大（ms/us）
  每个 flowop 的 ops/s

核心读：ops/s（操作吞吐，元数据操作占比高时比 MB/s 更重要）、Mb/s、各操作延迟。同样的磁盘，fileserver/varmail 的 ops/s 往往比顺序大块低一两个数量级——瓶颈在 inode 锁、journal、目录竞争而非带宽。

四、fio 还是 filebench

维度	fio	filebench
层级	块设备/文件均可，偏 IO 模式	文件系统/系统调用层
负载	顺序/随机、QD、引擎	业务画像（文件服务器/邮件/DB）
强项	极限 IOPS/带宽/延迟曲线	元数据、目录、fsync、缓存综合行为
调优对象	设备、调度器、队列	文件系统、挂载选项、日志、目录结构

选型：评估磁盘/云盘本身用 fio；比较 ext4/xfs、挂载选项（如 noatime、日志模式）、评估海量小文件和元数据性能用 filebench。测试时配合 iostat（await/%util）、slabtop（inode/dentry 缓存）观察。

坑

• 没改 $dir，压到了系统盘或根分区。
• fileset 太小被页缓存全部命中，测成内存速度；规模要大于缓存。
• 忽略 fsync 比例，得出和真实邮件/数据库完全不符的高吞吐。
• 预创建阶段耗时占满测试窗口，正式 run 太短，数据不稳定。
• 在有其它业务的文件系统上跑 varmail（大量 create/unlink），造成碎片和性能影响。

总结

filebench 通过 WML 用 fileset 描述文件规模、用 process/thread 描述并发、用 flowop 组合 open/read/write/fsync/create/stat 操作比例，从而模拟 fileserver、webserver、varmail、oltp 等真实业务在文件系统层的访问画像，输出 ops/s、吞吐和各操作延迟；它与 fio 互补——fio 测块设备极限 IOPS 与延迟，filebench 衡量元数据、目录、日志和挂载选项对实际工作负载的影响，测试时务必把 $dir 指向目标文件系统并让数据集大于缓存。