Question

我已经使用fio对我的SSD进行基准测试。但是，当fsync=1（在指定每个write()）参数后将脏缓冲区同步到磁盘时，我对报告的延迟感到困惑。

$ fio --name=test_seq_write --filename=test_seq --size=2G --readwrite=write --fsync=1
test_seq_write: (g=0): rw=write, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 1 process
test_seq_write: Laying out IO file(s) (1 file(s) / 2048MB)
Jobs: 1 (f=1): [W] [100.0% done] [0KB/31968KB/0KB /s] [0/7992/0 iops] [eta 00m:00s]
test_seq_write: (groupid=0, jobs=1): err= 0: pid=10994: Thu Oct 26 09:09:19 2017
  write: io=2048.0MB, bw=35647KB/s, iops=8911, runt= 58831msec
    clat (usec): min=2, max=1099, avg= 9.42, stdev=18.19
     lat (usec): min=2, max=1099, avg= 9.56, stdev=18.28

这里，iops是8911，因此延迟大约应该在100us左右。但是，报告的延迟是9us。我很好奇fio是否包括fsync的时间？我正在阅读fio doc，但没有找到任何解释。

Answer 1

（哦，天哪，如果你有任何选择，请不要使用蹩脚的旧版本的fio - 自fio 2.1.3以来你已经修复了很多错误，你继续使用它本身就是一种伤害（和build newer fio versions）并不需要花费太多时间。看看我们现在最近发布的fio版本：https://github.com/axboe/fio/releases）

以下答案适用于fio 3.4及更早版本。有关fio 3.5及更新版本，请参阅later answer to this question。

fsyncs是对常规I / O的单独fio操作（参见https://github.com/axboe/fio/blob/0bcf41cdc22dfee6b3f3b2ba9a533b4b103c70c2/io_u.c#L2170它们排队的位置）~~所以是的，它们应该被计算~~。 [更新]但是，fio明确排除了不是从统计信息收集中读取，写入或修剪的I / O（请参阅https://github.com/axboe/fio/blob/0bcf41cdc22dfee6b3f3b2ba9a533b4b103c70c2/io_u.c#L1823）。

所以

fio是否包含fsync的时间[在I / O延迟统计中]？

没有fio在延迟统计信息中不包含fsync时间。 fsync将影响总带宽，但这将无法分配。

注意：fsync是一项繁重的操作，因为在Linux上它确保：

I / O已被确认为被“磁盘”接收，而不仅仅是在Linux的页面缓存中。
与整个文件关联的元数据已刷新到磁盘。由于复杂的原因，这可能意味着您最终还在等待其他文件的数据/元数据被刷新...
“磁盘”已经确认I / O已经达到了稳定存储（即它不仅仅是在“磁盘”缓存中无法在失去电源的情况下继续存在）。

通常在进行基准测试时，您更有兴趣确保只有1.因为至少那时您更接近测试磁盘的速度（而不是Linux的缓存），而其他要点与确保数据完整性有关。如果这也是你的情况，我建议你使用fio的direct=1并停止使用fsync，因为每个I / O都将绕过Linux的页面缓存，直到磁盘确认收到I / O后才会返回。因此，每个I / O都会在其时间内构建“磁盘延迟”，但如上所述，这并不意味着第2或第3点。另请注意，并非所有文件系统都支持此选项（这很可惜）。

[原始推测]

然而，也可能是写I / O快速完成，fsyncs快速完成但每次提交之间的空间非零（主要是由于fio必须工作）。所以做I / O - ＆gt; I / O完成 - ＆gt;做非I / O工作 - ＆gt;做I / O等因此你不能从实现的IOP中推断出I / O延迟（你只能给它一个上限）。

PS：您可以使用现代 fio版本（http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-write-lat-log，http://fio.readthedocs.io/en/latest/fio_doc.html#log-file-formats，http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-log-avg-msec启用每I / O 日志记录（log_avg_msec必须为0 /未设置））但请注意，fsyncs也免于此日志记录。确保将日志保存在不会干扰测试的地方并注意每个I / O日志记录的增长速度非常快，因此在处于此模式时不要进行太多的I / O操作。

PPS：这个问题最好发送到fio邮件列表（https://github.com/axboe/fio/blob/fio-3.1/README#L58）。

Answer 2

fio 3.5 or later is now able to report fsync latencies！在执行符合以下所有条件的工作负载时，您将看到此信息：

执行某种形式的写作
有一个fsync/fdatasync/sync_file_range设置
--output-format是正常的（将有fsync / fdatasync / sync_file_range部分）或json / json +（这些值记录在＆＃34; sync＆＃34;方向下）。

以下是显示fsync延迟的正常输出示例：

$ ./fio --filename=/tmp/fio.tmp --size=1m --bs=512 --name=go --rw=write --fdatasync=1
go: (g=0): rw=write, bs=(R) 512B-512B, (W) 512B-512B, (T) 512B-512B, ioengine=psync, iodepth=1
[...]
go: (groupid=0, jobs=1): err= 0: pid=26958: Wed Feb 21 14:06:11 2018
  write: IOPS=512k, BW=250MiB/s (262MB/s)(1024KiB/4msec)
    clat (nsec): min=673, max=12144, avg=709.40, stdev=260.94
[...]
  lat (usec)   : 2=0.05%, 4=0.05%, 20=0.05%
  fsync/fdatasync/sync_file_range:
    sync (nsec): min=353, max=5307, avg=364.78, stdev=115.66
    sync percentiles (nsec):
     |  1.00th=[  358],  5.00th=[  358], 10.00th=[  358], 20.00th=[  362],
     | 30.00th=[  362], 40.00th=[  362], 50.00th=[  362], 60.00th=[  362],
     | 70.00th=[  362], 80.00th=[  362], 90.00th=[  366], 95.00th=[  366],
     | 99.00th=[  370], 99.50th=[  370], 99.90th=[  402], 99.95th=[ 2064],
     | 99.99th=[ 5280]
[...]

所以回答你的问题：

我很好奇fio是否包含fsync的时间？

在fio 3.3及以下否（请参阅https://stackoverflow.com/a/46968852/9109338中的更新）。在fio 3.5及以上版本中，那种 - fio在lat / clat延迟中不包含fsync（毕竟它不知道应该将fsync延迟归因于哪些I / O因为它无法检索该信息，但它会自行记录和报告fsync延迟。

fio基准延迟解释

2 个答案: