fioで観測されるiopsがiostatで観測されるものと異なるのはなぜですか？

Question

最近、私はfioを使ってディスクをテストしようとしています。

[global] 
invalidate=0 # mandatory 
direct=1 
#sync=1 
fdatasync=1 
thread=1 
norandommap=1 
runtime=10000 
time_based=1 

[write4k-rand] 
stonewall 
group_reporting 
bs=4k 
size=1g 
rw=randwrite 
numjobs=1 
iodepth=1 

をこの構成では、あなたは私が直接IOを使用してランダム書き込みを行うにはFIOが設定されていることを見ることができます：FIOの私の構成は以下のとおりです。テストが実行されている間、I/Oパフォーマンスを監視するためにiostatを使用しました。私はfdatasyncを1に設定した場合、fioで観測されるiopsは約64であり、iostatで観測されるiopsは約170であることがわかりました。これはなぜ異なっていますか？ "fdatasync"を構成しないと、両方のiopsはほぼ同じですが、はるかに高い約450です。なぜですか？私が知る限り、direct ioはページキャッシュを経由しません。私の意見では、fdatasyncを使用するかどうかは関係ありません。

そして、iostatが状況によっては間違った統計情報を提示する可能性があると聞きました。それは本当ですか？正確な状況によってiostatが間違ってしまうことがありますか？ I/Oパフォーマンスを監視するために使用できる他のツールはありますか？

Answer 1

ジョブファイルを見ると、ブロックデバイスに対してI/Oが実行されているのではなく、ファイルシステム内のファイルに対して実行されているようです。したがって、ファイルシステムに "そのファイルのその場所にこのデータを置く"ことを頼むかもしれないが、ファイルシステムは、そのファイルに関連するメタデータ（例えば、ジャーナル、ファイルのタイムスタンプ、コピー時のコピーなど）を更新する必要があるため、 ）あまりにも。したがって、要求がディスク（iostatで測定しているもの）に送信されると、元の要求が増幅されます。

また、Linuxにはそのディスクのioschedulerがある可能性があることにも注意してください。これにより、要求をディスクに提出する前に再編成、分割、マージしたり、スタックに戻したりすることができます。マージ/再配置のいくつかを回避する方法についてはnomergesのhttps://www.kernel.org/doc/Documentation/block/queue-sysfs.txtのさまざまなパラメータを参照してください。ただし、大きすぎるリクエストの分割を制御することはできません（ただし、ファイルシステムは過度に大きなリクエストを行いません）。

（PS：iostatが「間違っている」とは知らなかったので、直接言っている人に彼らが何を意味するのかを尋ねる必要があります）