简介fio-2.2.10.tar.gz 是面向 Linux 系统管理员、测试工程师与存储性能调优人员的开源 I/O 基准测试工具源码包用于评估硬盘、SSD、网络存储等设备的读写性能帮助定位存储瓶颈、验证存储方案效能。压缩包共 342 个文件约 573KB以 125 个 c 源文件与 146 个 h 头文件为主体构成核心测试引擎另有 38 个 fio 作业配置文件、makefile 与 configure 构建脚本、manpage 手册及 gnuplot 绘图脚本等覆盖编译、配置、运行与结果可视化全流程。该版本支持多线程并发、随机与顺序混合读写、队列深度调节并可输出 CSV、JSON 等报告格式便于导入分析工具深入解读。目前已有 409 人学习下载适合需要掌握 IOPS、吞吐量与延迟等关键指标、开展存储性能测试与调优实践的读者参考使用。1. fio-2.2.10.tar.gz一个老版本压测工具的翻新用法拿到fio-2.2.10.tar.gz这个包第一反应往往是「怎么是个老版本」。确实fio 早已更新到 3.x 系列2.2.10 属于十多年前的产物。但现实里它出现的频率并不低一些内网镜像站、嵌入式 SDK、老发行版的源码仓库里这个 tar.gz 还静静躺着。问题在于很多人解压后直接./configure make结果在较新的编译器上翻车或者跑起来发现某些参数行为和文档对不上。这篇笔记要解决的就是这件事把 fio-2.2.10.tar.gz 从解压到跑出一份可信的磁盘/文件系统压测报告完整走一遍。适合两类人——手里只有这个老包、又必须用它做 IO 基准测试的运维和存储工程师以及想搞懂 fio 参数到底怎么影响结果、不想被新版本封装层遮住细节的开发者。核心不是教你「fio 是什么」而是让这个特定版本的 tar.gz 在你机器上真正跑起来、结果能看、坑能绕开。2. 解压、编译与依赖让 2.2.10 在现代系统上活过来2.1 先看清包里有什么再决定编译路径fio-2.2.10.tar.gz是标准 GNU Autotools 工程解压后目录结构大致是configure、Makefile.in、fio.c、engines/、os/这些。先别急着 configure用两条命令确认环境和包内容tar -tzf fio-2.2.10.tar.gz | head -30 tar -xzf fio-2.2.10.tar.gz cd fio-2.2.10 ls -la第一条列出压缩包前 30 个条目确认没有路径穿越、没有奇怪的顶层目录嵌套第二条解压并进入。ls -la要重点看有没有configure和Makefile.in如果只有Makefile而没有configure说明这个包可能是二次打包的编译方式完全不同。2.2.10 的configure脚本生成于老版本 autoconf在新系统上可能报cannot find install-sh或aclocal相关错误。常见做法是先补上基础构建链sudo apt-get install -y build-essential autoconf automake libtool # CentOS/RHEL 系用sudo yum groupinstall Development Tools这里build-essential提供 gcc、make、libc 头文件autoconf/automake/libtool是为了在configure失效时能重新生成。注意 2.2.10 依赖的是老式 autotools 语法新版 automake 可能不兼容所以优先尝试直接用包内自带的configure而不是一上来就autoreconf。2.2 configure 的关键开关与参数含义直接./configure通常能过但有几个开关决定后面能不能测到你想测的东西./configure \ --prefix/usr/local/fio-2.2.10 \ --disable-native \ --enable-libaio \ --enable-gfio 21 | tee configure.log--prefix安装到独立目录避免覆盖系统里可能存在的其他 fio 版本这对老版本尤其重要。--disable-native关闭针对本机 CPU 的激进优化。老版本在-marchnative下有时会生成非法指令尤其在跨机器编译时。--enable-libaio启用 Linux 原生异步 IO 引擎。如果你要测的是ioenginelibaio这个必须开否则 configure 会静默跳过运行时才报 engine not found。--enable-gfio带图形化输出支持依赖 gtk/glib。如果机器上没有桌面环境这个开关会导致 configure 失败可以去掉。configure 结束后看configure.log末尾的 summary确认libaio显示为 yes。如果显示 no检查libaio-devel是否安装sudo apt-get install -y libaio-dev # 或 sudo yum install -y libaio-devel2.3 编译报错的三类典型修法2.2.10 在新 gcc9 以上上编译最容易撞三类错误。第一类是-Werror导致的警告升级为错误现象是某个.c文件里implicit declaration of function直接中断。解决是去掉 Werrormake CFLAGS-O2 -g -Wno-error 21 | tee make.log第二类是getrandom或clock_gettime链接失败报undefined reference。这是老版本没链接-lrt手动补make LDFLAGS-lrt -lpthread 21 | tee make.log第三类是os/目录下平台判断出错比如在较新的内核头文件上sys/ioctl.h冲突。这种情况优先看make.log里第一个 error 出现的文件而不是最后一个因为后续错误往往是连锁的。编译成功后make install然后验证/usr/local/fio-2.2.10/bin/fio --version输出应类似fio-2.2.10。如果报error while loading shared libraries执行ldd看缺哪个 so通常是 libaio补装运行时库即可。3. 用 fio-2.2.10 跑出第一份可信的 IO 报告3.1 最小可用 job 文件与每个参数的作用fio 的用法是「一个 job 文件描述一次压测」。2.2.10 的 job 语法和 3.x 基本一致但个别参数名有差异。先写一个最小可用的顺序读测试[global] ioenginelibaio direct1 runtime30 time_based1 group_reporting1 filename/data/testfile size2G [seq-read] rwread bs128k iodepth16 numjobs1逐项说明ioenginelibaio走 Linux 异步 IO能压出高 iodepth。如果编译时没开 libaio这里会直接报错。direct1绕过 page cache。测磁盘真实性能必须开否则读的是内存数字虚高。runtime30time_based1强制跑满 30 秒而不是把 2G 文件读完就停。这样不同配置之间才有可比性。group_reporting1多 job 时汇总输出避免刷屏。filenamesize指定测试文件和大小。注意size是每个 job 的文件大小多 job 时会叠加。运行/usr/local/fio-2.2.10/bin/fio seq-read.fio输出里重点看bw带宽、iops、lat (msec)的 avg 和 99.00 分位。2.2.10 的百分位输出格式和 3.x 略有不同99 分位可能标为99.00th含义一致。3.2 随机读写与 iodepth 的配合关系顺序读只能看带宽真正区分存储介质的是随机读写。把 job 改成随机写[rand-write] rwrandwrite bs4k iodepth32 numjobs4这里iodepth32配合numjobs4实际队列深度是 128。2.2.10 在 libaio 引擎下iodepth是每个 job 的队列深度总深度是乘积。很多人只改iodepth不改numjobs发现 IOPS 上不去就是因为单队列被内核或设备限住了。跑之前建议先清缓存避免上一次测试的残留影响sync echo 3 /proc/sys/vm/drop_caches注意drop_caches需要 root且只影响 page cache不影响设备自身缓存。如果设备有写缓存且未开direct结果依然不可信。3.3 结果解读哪些数字能信哪些是假象一份 fio 报告里最容易被误读的是lat和clat。lat是总延迟包括排队clat是完成延迟不含排队。高 iodepth 下lat远大于clat是正常的说明瓶颈在队列调度而非设备本身。另一个坑是bw单位。2.2.10 默认输出KB/s但这里的 K 是 1024 还是 1000取决于编译时的定义。稳妥做法是看iops和bs自己算iops * bs / 1024 / 1024得到 MiB/s和报告里的bw对照偏差超过 5% 就要查单位换算。还有slat提交延迟在 libaio 下通常很小如果slat异常大说明 CPU 或内核调度有问题而不是磁盘慢。这时候要看%util和await用 iostat 配合交叉验证。4. 避坑与排查2.2.10 特有的五个翻车现场4.1 现象configure 通过但 make 报 engine 缺失原因--enable-libaio虽然写了但 configure 检测到libaio.h不存在时不会报错只是静默禁用。解决configure 后 grep 日志确认grep -i libaio configure.log如果输出checking for libaio.h... no补装libaio-dev后重新 configure不要直接 make。4.2 现象跑起来报fio: pidxxx, got signal11原因段错误多半是direct1配合某些文件系统如 tmpfs、overlayfs不支持 O_DIRECT。解决换到 ext4/xfs 的块设备或普通目录或者临时去掉direct1验证。注意去掉 direct 后结果不能用于磁盘选型。4.3 现象IOPS 远低于预期但 iostat 显示设备很闲原因numjobs和iodepth乘积不够或者 job 文件里rw写成了randread但bs太大如 1M导致实际变成顺序读。解决随机测试固定bs4k或8k逐步加iodepth直到 IOPS 不再上升那个拐点才是设备真实能力。4.4 现象两次相同配置结果差异超过 20%原因没有清缓存或者后台有其他 IO。解决每次测试前drop_caches并用iostat -x 1确认没有其他进程在读写同一设备。另外 2.2.10 的runtime是软限制实际可能多跑几秒对比时统一看bw而非总字节数。4.5 现象make install后命令找不到原因--prefix设到了非 PATH 目录。解决用绝对路径调用或临时加 PATHexport PATH/usr/local/fio-2.2.10/bin:$PATH不要直接cp到/usr/bin会和系统包管理器冲突后期升级或卸载都麻烦。5. 进阶用 2.2.10 做可复现的对比测试与结果归档老版本 fio 最大的价值不是功能多而是行为稳定——同一份 job 文件在不同机器上跑结果可比性强。我一般会建一个测试目录把 job 文件、configure 日志、make 日志、fio 输出全部按时间戳归档mkdir -p ~/fio-bench/$(date %Y%m%d-%H%M%S) cd ~/fio-bench/$(date %Y%m%d-%H%M%S) cp /path/to/seq-read.fio . /usr/local/fio-2.2.10/bin/fio seq-read.fio --outputseq-read.json --output-formatjson--output-formatjson在 2.2.10 里已经支持输出结构化数据方便后续用 jq 或 python 提取关键指标做对比表指标字段路径用途带宽jobs[0].read.bw顺序读能力IOPSjobs[0].write.iops随机写能力平均延迟jobs[0].read.lat_ns.mean延迟基线99 分位延迟jobs[0].read.lat_ns.percentile[99.000000]尾延迟用 jq 提取jq .jobs[0].read.bw, .jobs[0].read.lat_ns.mean seq-read.json注意 2.2.10 的 JSON 字段名和 3.x 有差异比如lat_ns在 3.x 里可能叫lat_ns但结构不同直接套用 3.x 的解析脚本会拿到 null。稳妥做法是先jq keys看顶层结构再逐层下钻。另一个技巧是固定 CPU 亲和性减少调度抖动taskset -c 2-5 /usr/local/fio-2.2.10/bin/fio rand-write.fio把 fio 绑到独立核心避免和其他进程抢 CPU。2.2.10 本身不支持--cpus_allowed参数3.x 才有所以用taskset是更可靠的方式。最后说个血泪经验老版本 fio 的runtime在time_based1下如果某个 job 提前完成比如文件被写满整个测试会提前结束而不是等满 runtime。所以size一定要给足或者用filesize配合nrfiles让每个 job 有足够空间。我一般会把size设成runtime * 预期带宽 * 1.5留出余量。希望帮到你。本文还有配套的精品资源点击获取 fio-2.2.10.tar.gz 老版本压测工具编译与IO基准测试实战
简介fio-2.2.10.tar.gz 是面向 Linux 系统管理员、测试工程师与存储性能调优人员的开源 I/O 基准测试工具源码包用于评估硬盘、SSD、网络存储等设备的读写性能帮助定位存储瓶颈、验证存储方案效能。压缩包共 342 个文件约 573KB以 125 个 c 源文件与 146 个 h 头文件为主体构成核心测试引擎另有 38 个 fio 作业配置文件、makefile 与 configure 构建脚本、manpage 手册及 gnuplot 绘图脚本等覆盖编译、配置、运行与结果可视化全流程。该版本支持多线程并发、随机与顺序混合读写、队列深度调节并可输出 CSV、JSON 等报告格式便于导入分析工具深入解读。目前已有 409 人学习下载适合需要掌握 IOPS、吞吐量与延迟等关键指标、开展存储性能测试与调优实践的读者参考使用。1. fio-2.2.10.tar.gz一个老版本压测工具的翻新用法拿到fio-2.2.10.tar.gz这个包第一反应往往是「怎么是个老版本」。确实fio 早已更新到 3.x 系列2.2.10 属于十多年前的产物。但现实里它出现的频率并不低一些内网镜像站、嵌入式 SDK、老发行版的源码仓库里这个 tar.gz 还静静躺着。问题在于很多人解压后直接./configure make结果在较新的编译器上翻车或者跑起来发现某些参数行为和文档对不上。这篇笔记要解决的就是这件事把 fio-2.2.10.tar.gz 从解压到跑出一份可信的磁盘/文件系统压测报告完整走一遍。适合两类人——手里只有这个老包、又必须用它做 IO 基准测试的运维和存储工程师以及想搞懂 fio 参数到底怎么影响结果、不想被新版本封装层遮住细节的开发者。核心不是教你「fio 是什么」而是让这个特定版本的 tar.gz 在你机器上真正跑起来、结果能看、坑能绕开。2. 解压、编译与依赖让 2.2.10 在现代系统上活过来2.1 先看清包里有什么再决定编译路径fio-2.2.10.tar.gz是标准 GNU Autotools 工程解压后目录结构大致是configure、Makefile.in、fio.c、engines/、os/这些。先别急着 configure用两条命令确认环境和包内容tar -tzf fio-2.2.10.tar.gz | head -30 tar -xzf fio-2.2.10.tar.gz cd fio-2.2.10 ls -la第一条列出压缩包前 30 个条目确认没有路径穿越、没有奇怪的顶层目录嵌套第二条解压并进入。ls -la要重点看有没有configure和Makefile.in如果只有Makefile而没有configure说明这个包可能是二次打包的编译方式完全不同。2.2.10 的configure脚本生成于老版本 autoconf在新系统上可能报cannot find install-sh或aclocal相关错误。常见做法是先补上基础构建链sudo apt-get install -y build-essential autoconf automake libtool # CentOS/RHEL 系用sudo yum groupinstall Development Tools这里build-essential提供 gcc、make、libc 头文件autoconf/automake/libtool是为了在configure失效时能重新生成。注意 2.2.10 依赖的是老式 autotools 语法新版 automake 可能不兼容所以优先尝试直接用包内自带的configure而不是一上来就autoreconf。2.2 configure 的关键开关与参数含义直接./configure通常能过但有几个开关决定后面能不能测到你想测的东西./configure \ --prefix/usr/local/fio-2.2.10 \ --disable-native \ --enable-libaio \ --enable-gfio 21 | tee configure.log--prefix安装到独立目录避免覆盖系统里可能存在的其他 fio 版本这对老版本尤其重要。--disable-native关闭针对本机 CPU 的激进优化。老版本在-marchnative下有时会生成非法指令尤其在跨机器编译时。--enable-libaio启用 Linux 原生异步 IO 引擎。如果你要测的是ioenginelibaio这个必须开否则 configure 会静默跳过运行时才报 engine not found。--enable-gfio带图形化输出支持依赖 gtk/glib。如果机器上没有桌面环境这个开关会导致 configure 失败可以去掉。configure 结束后看configure.log末尾的 summary确认libaio显示为 yes。如果显示 no检查libaio-devel是否安装sudo apt-get install -y libaio-dev # 或 sudo yum install -y libaio-devel2.3 编译报错的三类典型修法2.2.10 在新 gcc9 以上上编译最容易撞三类错误。第一类是-Werror导致的警告升级为错误现象是某个.c文件里implicit declaration of function直接中断。解决是去掉 Werrormake CFLAGS-O2 -g -Wno-error 21 | tee make.log第二类是getrandom或clock_gettime链接失败报undefined reference。这是老版本没链接-lrt手动补make LDFLAGS-lrt -lpthread 21 | tee make.log第三类是os/目录下平台判断出错比如在较新的内核头文件上sys/ioctl.h冲突。这种情况优先看make.log里第一个 error 出现的文件而不是最后一个因为后续错误往往是连锁的。编译成功后make install然后验证/usr/local/fio-2.2.10/bin/fio --version输出应类似fio-2.2.10。如果报error while loading shared libraries执行ldd看缺哪个 so通常是 libaio补装运行时库即可。3. 用 fio-2.2.10 跑出第一份可信的 IO 报告3.1 最小可用 job 文件与每个参数的作用fio 的用法是「一个 job 文件描述一次压测」。2.2.10 的 job 语法和 3.x 基本一致但个别参数名有差异。先写一个最小可用的顺序读测试[global] ioenginelibaio direct1 runtime30 time_based1 group_reporting1 filename/data/testfile size2G [seq-read] rwread bs128k iodepth16 numjobs1逐项说明ioenginelibaio走 Linux 异步 IO能压出高 iodepth。如果编译时没开 libaio这里会直接报错。direct1绕过 page cache。测磁盘真实性能必须开否则读的是内存数字虚高。runtime30time_based1强制跑满 30 秒而不是把 2G 文件读完就停。这样不同配置之间才有可比性。group_reporting1多 job 时汇总输出避免刷屏。filenamesize指定测试文件和大小。注意size是每个 job 的文件大小多 job 时会叠加。运行/usr/local/fio-2.2.10/bin/fio seq-read.fio输出里重点看bw带宽、iops、lat (msec)的 avg 和 99.00 分位。2.2.10 的百分位输出格式和 3.x 略有不同99 分位可能标为99.00th含义一致。3.2 随机读写与 iodepth 的配合关系顺序读只能看带宽真正区分存储介质的是随机读写。把 job 改成随机写[rand-write] rwrandwrite bs4k iodepth32 numjobs4这里iodepth32配合numjobs4实际队列深度是 128。2.2.10 在 libaio 引擎下iodepth是每个 job 的队列深度总深度是乘积。很多人只改iodepth不改numjobs发现 IOPS 上不去就是因为单队列被内核或设备限住了。跑之前建议先清缓存避免上一次测试的残留影响sync echo 3 /proc/sys/vm/drop_caches注意drop_caches需要 root且只影响 page cache不影响设备自身缓存。如果设备有写缓存且未开direct结果依然不可信。3.3 结果解读哪些数字能信哪些是假象一份 fio 报告里最容易被误读的是lat和clat。lat是总延迟包括排队clat是完成延迟不含排队。高 iodepth 下lat远大于clat是正常的说明瓶颈在队列调度而非设备本身。另一个坑是bw单位。2.2.10 默认输出KB/s但这里的 K 是 1024 还是 1000取决于编译时的定义。稳妥做法是看iops和bs自己算iops * bs / 1024 / 1024得到 MiB/s和报告里的bw对照偏差超过 5% 就要查单位换算。还有slat提交延迟在 libaio 下通常很小如果slat异常大说明 CPU 或内核调度有问题而不是磁盘慢。这时候要看%util和await用 iostat 配合交叉验证。4. 避坑与排查2.2.10 特有的五个翻车现场4.1 现象configure 通过但 make 报 engine 缺失原因--enable-libaio虽然写了但 configure 检测到libaio.h不存在时不会报错只是静默禁用。解决configure 后 grep 日志确认grep -i libaio configure.log如果输出checking for libaio.h... no补装libaio-dev后重新 configure不要直接 make。4.2 现象跑起来报fio: pidxxx, got signal11原因段错误多半是direct1配合某些文件系统如 tmpfs、overlayfs不支持 O_DIRECT。解决换到 ext4/xfs 的块设备或普通目录或者临时去掉direct1验证。注意去掉 direct 后结果不能用于磁盘选型。4.3 现象IOPS 远低于预期但 iostat 显示设备很闲原因numjobs和iodepth乘积不够或者 job 文件里rw写成了randread但bs太大如 1M导致实际变成顺序读。解决随机测试固定bs4k或8k逐步加iodepth直到 IOPS 不再上升那个拐点才是设备真实能力。4.4 现象两次相同配置结果差异超过 20%原因没有清缓存或者后台有其他 IO。解决每次测试前drop_caches并用iostat -x 1确认没有其他进程在读写同一设备。另外 2.2.10 的runtime是软限制实际可能多跑几秒对比时统一看bw而非总字节数。4.5 现象make install后命令找不到原因--prefix设到了非 PATH 目录。解决用绝对路径调用或临时加 PATHexport PATH/usr/local/fio-2.2.10/bin:$PATH不要直接cp到/usr/bin会和系统包管理器冲突后期升级或卸载都麻烦。5. 进阶用 2.2.10 做可复现的对比测试与结果归档老版本 fio 最大的价值不是功能多而是行为稳定——同一份 job 文件在不同机器上跑结果可比性强。我一般会建一个测试目录把 job 文件、configure 日志、make 日志、fio 输出全部按时间戳归档mkdir -p ~/fio-bench/$(date %Y%m%d-%H%M%S) cd ~/fio-bench/$(date %Y%m%d-%H%M%S) cp /path/to/seq-read.fio . /usr/local/fio-2.2.10/bin/fio seq-read.fio --outputseq-read.json --output-formatjson--output-formatjson在 2.2.10 里已经支持输出结构化数据方便后续用 jq 或 python 提取关键指标做对比表指标字段路径用途带宽jobs[0].read.bw顺序读能力IOPSjobs[0].write.iops随机写能力平均延迟jobs[0].read.lat_ns.mean延迟基线99 分位延迟jobs[0].read.lat_ns.percentile[99.000000]尾延迟用 jq 提取jq .jobs[0].read.bw, .jobs[0].read.lat_ns.mean seq-read.json注意 2.2.10 的 JSON 字段名和 3.x 有差异比如lat_ns在 3.x 里可能叫lat_ns但结构不同直接套用 3.x 的解析脚本会拿到 null。稳妥做法是先jq keys看顶层结构再逐层下钻。另一个技巧是固定 CPU 亲和性减少调度抖动taskset -c 2-5 /usr/local/fio-2.2.10/bin/fio rand-write.fio把 fio 绑到独立核心避免和其他进程抢 CPU。2.2.10 本身不支持--cpus_allowed参数3.x 才有所以用taskset是更可靠的方式。最后说个血泪经验老版本 fio 的runtime在time_based1下如果某个 job 提前完成比如文件被写满整个测试会提前结束而不是等满 runtime。所以size一定要给足或者用filesize配合nrfiles让每个 job 有足够空间。我一般会把size设成runtime * 预期带宽 * 1.5留出余量。希望帮到你。本文还有配套的精品资源点击获取