ブロックサイズとIOの関係は何ですか？
最近ディスクについて読んでいて、3つの疑問が浮かびました。そして、それらを一緒にリンクすることはできません。私が混乱している3つの異なる用語は、_block size_、IOおよびPerformanceです。
ステートメントに遭遇したとき、私は slashroot でスーパーブロックについて読んでいました
ファイルシステムのブロックサイズが大きい場合、実行されるIOPSは少なくなります。
これから、1024 KBのデータを読み取りたい場合、ブロックサイズが4KB/4096Bのディスク（Aなど）は、ブロックサイズのディスク（Bなど）よりも多くのIO 64KBの。
さて、私の質問は、ディスクAがどれほど必要かということですIO.
私が理解している限り、このデータを読み取るために必要なIO要求の数も、各IO要求のサイズに依存します。
- _
So who is deciding what is the size of the IO request? Is it equal to the block size?_一部の人々は、アプリケーションがIO要求のサイズを十分に決定しますが、OSが単一の要求を複数のIOにどのように分割するかを決定します。_There must be a limit after which the request splits in more then one IO. How to find that limit ?_ Is it possible that in both disk (A and B) the data can be read in same number of IO?- _
Does reading each block means a single IO ? If not how many blocks can be maximum read in a single IO?_ - _
If the data is sequential or random spread, does CPU provides all block address to read once?_
また
可能なIOPSの数= 1 /（平均回転遅延+平均シーク時間）
スループット= IOPS * IOサイズ
上記の場合、ディスクのIOPSは常に修正されますが、IOサイズは可変である可能性があります。したがって、可能な最大スループットを計算するには、最大IOサイズが必要です。これから私が理解していることは、ディスクからスループットを向上させたい場合、リクエストで送信できる最大のデータでリクエストを実行することになります。この仮定は正しいですか？
質問が多すぎて申し訳ありませんが、しばらく読んでいて満足のいく答えが得られませんでした。同じものに対して異なる見解を見つけました。
Wikipediaの記事 で十分に説明されていると思います。
応答時間とワークロードの同時指定がない場合、IOPSは本質的に意味がありません。
...
ベンチマークと同様に、ストレージデバイスの製造元によって公開されたIOPSの数値は、実際のアプリケーションのパフォーマンスとは直接関係ありません。 ...
今あなたの質問に：
IOリクエストのサイズは何ですか？
それは、私のようなプログラマーではない人にとっては、簡単で難しい質問です。
いつものように、答えは不十分です "それは依存します" ...
アプリケーションによるディスクストレージに関するI/O操作は、通常、オペレーティングシステムへのシステムコールであり、そのサイズは、実行されるシステムコールによって異なります...
私は他のオペレーティングシステムよりもLinuxに精通しているので、それを参照として使用します。
open() 、 stat() 、 chmod()などのI/O操作のサイズ と同様のものはほとんど無視できます。
回転ディスクでは、これらの呼び出しのパフォーマンスは主に、ディスクアクチュエータがアームを動かし、ヘッドをディスクプラッター上の正しい位置に読み取るために必要な量に依存します。
一方、 read() および write() 呼び出しのサイズはアプリケーションによって最初に設定され、0と単一のI/O要求の0x7ffff000（2,147,479,552）バイト...
もちろん、このようなシステムコールがアプリケーションによって行われ、OSによって受信されると、コールは scheduled and queued （O_DIRECTフラグがバイパスされたかどうかに応じて）ページキャッシュとバッファ、およびダイレクトI/Oが選択されました）。
抽象システムコールは、個別の blocks （通常、ファイルシステムが作成されたときに設定されたサイズ）で順序付けられる、基礎となるファイルシステムの操作との間でマッピングされる必要があります。ディスクドライバーは ハードディスクセクター 512または4096バイトのSSDまたは2K、4K、8K、または16KのSSDメモリページで動作します。
（通常、ベンチマークの場合、読み取りと書き込みの呼び出しは通常、512Bまたは4KBに設定されます。これらは、基盤となるディスクと非常によく整合し、最適なパフォーマンスをもたらします。）
制限がなければ、リクエストは複数のIOに分割されます。その限界を見つける方法は？
はい、制限があります。Linuxでは、マニュアルに記載されているように、単一の read() または write() システムコールが最大値を返します0x7ffff000（2,147,479,552）バイト。より大きなファイルをより大きく読み取るには、追加のシステムコールが必要になります。
各ブロックを読み取ることは、1つのIO？
私が理解している限り、通常、システムコールが発生するたびにIOイベントとしてカウントされます。
単一のread()システムコールは、ファイルシステムからXブロックにアクセスしたり、回転しているハードディスクからYセクターを読み込んだりするためにシステムコールがどのように変換/実装されるかに関係なく、1 I/0イベントとしてカウントされ、XとY IOのどちらもカウントされません。 。
このステートメントをデコードしようとしているようです：
「ファイルシステムのブロックサイズが大きい場合、IOPSは少なくなります。」
元の著者の意味をより明確にするために、このステートメントを言い換えてみましょう。
「特定のサイズ（たとえば、10MB）で指定されたファイルを読み取るには、より大きなブロックサイズでフォーマットされたファイルシステムはおそらくファイルシステムよりも少ない数の読み取り操作を実行する必要がありますより小さなブロックサイズでフォーマットされています。」
私の言い回しがオリジナルよりも少し意味があるといいのですが。
そのステートメントを適切に解析し、a）ディスクの代わりに「ファイルシステム」という用語を使用し、b）おそらく「おそらく」厄介な理由を理解するには、データが存在するすべてのソフトウェア層について、さらに多くのことを学ぶ必要があります。ディスク（またはSSD）とユーザーランドアプリケーション。グーグルを開始するためのヒントをいくつか紹介します。
回転ディスクの場合：
- セクターサイズ（ディスク）とブロックサイズ（ファイルシステム）
キャッシングについて学ぶ：
OSカーネルのページ/バッファキャッシュ
ユーザーレベルライブラリでのI/Oキャッシング（最も重要なのはlibcとlibc ++です）
SSDまたはその他のフラッシュベースのストレージの場合、さらに複雑な問題がいくつかあります。フラッシュストレージがページ単位でどのように機能するか、およびフラッシュベースのストレージにガベージコレクションプロセスが必要な理由を調べる必要があります。