fio使用以下设置在新服务器上运行了一些测试：
- 1 个三星 PM981a 512GB M.2 NVMe 驱动器。
- Proxmox 在根目录上使用 ZFS 进行安装。
- 1x VM，创建了 30GB 空间并安装了 Debian 10。
- 6 个 Intel P4510 2TB U.2 NVMe 驱动器通过 OCuLink 连接到 6 个专用 PCIe 4.0 x4 通道。
- 直接连接到单个虚拟机。
- 在虚拟机中配置为 RAID10（3x 镜像条带化）。
- 主板/CPU/内存：华硕 KRPA-U16/EPYC 7302P/8x32GB DDR4-3200
这些磁盘的额定高达 3,200 MB/s顺序读取。从理论角度来看，最大带宽应为 19.2 GB/s。
fio在ZFS RAID 上运行时numjobs=1，我得到的结果范围在 ~2,000 - 3,000 MB/s 之间（在没有 ZFS 或任何其他开销的情况下进行测试时，磁盘能够达到完整的 3,200 MB/s，例如，在直接安装在其中一个磁盘上的 Windows 中运行 Crystal Disk Mark 时）：
fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=1 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
READ: bw=2939MiB/s (3082MB/s), 2939MiB/s-2939MiB/s (3082MB/s-3082MB/s), io=100GiB (107GB), run=34840-34840msec
从各方面考虑似乎都合理。也可能是 CPU 受限，因为其中一个核心的负载为 100%（其中一部分用于 ZFS 进程）。
当我增加到numjobs8-10 时，事情变得有点奇怪：
fio --name=Test --size=100G --bs=1M --iodepth=8 --numjobs=10 --rw=read --filename=fio.test
=>
Run status group 0 (all jobs):
READ: bw=35.5GiB/s (38.1GB/s), 3631MiB/s-3631MiB/s (3808MB/s-3808MB/s), io=1000GiB (1074GB), run=28198-28199msec
38.1 GB/s——远高于理论最大带宽。
这里究竟解释什么呢？
补充评论：
虚拟机配置：
iotop测试期间：
答案1
第一个fio（带有 的那个--numjobs=1）顺序执行任何读取操作，除了快速预读/预取之外，不会从条带配置中受益：iodepth仅适用于通过libaio引擎完成的异步读取，而这又需要真正的支持O_DIRECT（ZFS 缺乏）。您可以尝试将预取窗口从默认的 8M 增加到 64M（echo 67108864 > /sys/module/zfs/parameters/zfetch_max_distance）。当然，您的里程可能会有所不同，因此请务必检查这不会损害其他工作负载。
第二个fio（带有--numjobs=8）可能因 ARC 缓存而出现偏差。为确保万无一失，只需打开另一个运行 的终端dstat -d -f：您将看到每个磁盘的真实传输速度，并且它肯定会与其理论最大传输速率一致。您还可以fio使用新启动的机器（即空的 ARC）重试测试，看看情况是否有变化。
答案2
对于具有多个作业的顺序 I/O 测试，每个作业（即线程）都有一个线程特定的文件指针（原始设备的块地址），默认情况下从零开始，独立于其他线程前进。这意味着 fio 将向文件系统发出读取请求，并在作业中使用重复/重叠的文件指针/块地址。如果您使用该write_iolog选项，您可以看到这一点。重叠的请求会使基准测试结果产生偏差，因为它们很可能由读取缓存满足，无论是在文件系统中（测试文件时）还是由设备（在原始卷上运行时）。
您需要的是一个单一作业，然后iodepth专门修改参数以控制 I/O 队列深度。这指定了每个作业允许活动的并发 I/O 数量。
唯一的缺点是总可实现 IOP 可能会受到单核/线程的限制。对于大块顺序工作负载，这应该不是问题，因为它们不受 IOP 限制。对于随机 I/O，您肯定希望使用多个作业，尤其是在可以处理超过一百万 IOP 的 NVMe 驱动器上。