必须测试裸设备（如/dev/vdb）以反映真实磁盘性能，但严禁使用系统盘（如/dev/vda）或已有数据盘，否则将破坏文件系统；应先用sudo fdisk -lu确认空闲未分区设备，并确保未挂载、无文件系统。
直接测裸设备才能反映真实磁盘性能，但必须避开系统盘和已有数据盘，否则会丢数据。
怎么选测试目标设备
先用 sudo fdisk -lu 看设备列表，确认哪个是空闲数据盘（比如 /dev/vdb），别碰 /dev/vda 这类系统盘；如果设备已挂载或有文件系统（如 /dev/mapper/centos-root），绝对不能指定它——fio 会直接写裸扇区，瞬间破坏文件系统。
- 推荐只测未分区、未格式化的空盘，比如
/dev/vdb（不是/dev/vdb1） - 云环境建议用新购的独立数据盘，测试完按需重新初始化或释放
- 机械盘和 SSD 对
iodepth敏感度不同：SSD 可设32～128，机械盘建议8～16
关键参数组合怎么配
参数不是随便堆，得按目标指标来配。测 IOPS 就用小块随机读写，测吞吐就用大块顺序读写，混搭错一个，结果就失真。
- 测 4K 随机读 IOPS：
fio -rw=randread -bs=4k -iodepth=32 -numjobs=4 -direct=1 -ioengine=libaio - 测 1M 顺序写吞吐：
fio -rw=write -bs=1M -iodepth=16 -numjobs=1 -direct=1 -ioengine=sync（顺序写不用 libaio，避免队列干扰） - 混合读写（如数据库场景）：
fio -rw=randrw -rwmixread=70 -bs=4k -iodepth=32 - 所有命令都必须加
-direct=1，否则缓存介入，测的是内存不是磁盘
为什么测试结果不准？常见坑点
很多人的测试结果波动大、数值虚高，往往不是盘不行，而是参数或环境没控住。
-
libaio-devel没装会导致ioengine=libaio失效，降级成同步 IO，IOPS 跌 90% 以上 - 没加
-group_reporting时，多numjobs的输出是分散的，容易误读单个线程值而非总和 - SSD 测试前不预热（比如先跑一轮
randwrite持续 5 分钟），首分钟可能因缓存/FTL 未稳定，延迟偏高、IOPS 偏低 - 测试中没用
iostat -x 1实时观察%util和await，光看 fio 输出容易忽略设备是否真正饱和
测试后要不要清理设备
只要测的是裸设备（/dev/vdb 这种），测试过程就已覆盖原始扇区，原有分区表和文件系统必然损坏。这不是 bug，是预期行为。
- 若设备原无数据，测试完可直接分区格式化使用
- 若设备曾有重要数据，必须提前打快照或备份，且测试后不能跳过重新初始化步骤
- 别信“测试完还能继续用”，哪怕只跑 1 秒
randwrite，ext4 的 superblock 或 xfs 的 AG header 都可能被覆写
