ここでは、小さなストライプサイズがLinuxのソフトウェア（およびハードウェア）RAID 5および6に適していないことを読んでいます。私が見た珍しいベンチマークはこれに完全に同意します。
しかし、与えられた説明は、それがより多くの頭の動きを引き起こすということです。私は小さなストライプがどのように頭を動かすのか理解していません。
4つのローカルSASドライブを含むRAID 6設定があるとします。
ケース1：1Gbの順次データ書き込み
プログラムはカーネルにデータの書き込みを要求し、それをストライプサイズに合わせて分割し、各ディスクに書き込む各ブロック（データおよび/またはパリティ）を計算します。
カーネルは、適切なディスクコントローラを使用して4つのディスクに同時に書き込むことができます。
記録されたデータがストライプと完全に整列していない場合、カーネルは結果データを計算する前に最初と最後のストライプのみを読み取る必要があります。他のすべてのストリップは、以前のデータに関係なく上書きされます。
この計算はディスクスループットよりはるかに速く完了するため、各ブロックは一時停止せずに各ディスクの前のブロックのすぐ隣に書き込まれます。したがって、これは基本的に4つのディスクへの順次書き込みです。
小さなストライプサイズのため、どのように速度が遅くなりますか？
ケース2：ランダムな位置に1,000,000 x 1kbのデータを書き込みます。
1kbはストライプサイズ（現在の一般的なストライプサイズは512kb）より小さく、
プログラムはカーネルにいくつかのデータ、他のデータ、再び他のデータなどを書き込むように要求します。各書き込みに対して、カーネルは現在のデータを読み取る必要があります。データをディスクに保存し、新しいコンテンツを計算してディスクに書き戻します。その後、頭が別の場所に移動し、作業が999,999回繰り返されます。
ストライプサイズが小さいほど、データの読み取り/計算/書き込み速度が速くなります。理想的には、4kbのストライプサイズが最新のディスクに最適です（正しく配置されている場合）。
それでは、小さなストリップサイズはどのように速度を遅くするのですか？
答え1
私が知る限り、この問題は頭の動きに関連しているわけではなく、すべてのオーバーヘッドが原因で発生します。指定された順次読み取りまたは書き込みの場合、4KBストライプサイズは64KBストライプサイズより16倍多くの操作を実行します。より多くのCPU時間、より多くのメモリ帯域幅、より多くのコンテキスト切り替え、より多くのI / O、カーネルI / Oスケジューラのより多くの作業、より多くの計算のマージなどにより、最終的にすべてのI / OOにはより多くの遅延があります発生します。
多くのアプリケーションはキューサイズが1のI / Oを実行しているため、16個の4KB順次要求をディスクへの64KB要求に常に統合できるわけではありません。
また、一般的なATTOディスクのベンチマークを見ると、次のようになります。
128KB以上のブロックで読み取りが完了するまで、ディスクは最高速度で順次読み取ることができないことがわかります。
Tomshardwareは、ストライプサイズの影響について非常に包括的なレビューを提供します。
http://www.tomshardware.com/reviews/RAID-SCALING-CHARTS,1735.html
答え2
私はLinuxソフトウェアRAIDについて話しています。見たときコードを入力、mdドライバが完全に最適化されていないことがわかります。複数の連続した要求が生成される場合、md ドライバーはより大きな要求にマージされません。いくつかの一般的なケースでは、これはかなりのオーバーヘッドを引き起こす可能性があります。
大規模な読み取りまたは書き込みは最適化されます。ストライプと同じサイズのいくつかの要求に縮小され、最適に処理されます。
読み取りまたは書き込みが2つのストライプにまたがる場合、mdドライバは正しく動作します。すべてが一度の操作として扱われます。
小さな読み出しの場合、最初の読み込み後にデータがカーネルキャッシュにあるので問題はありません。したがって、多重連続読み取りは、低速のディスク帯域幅と比較して、CPUとメモリに小さなオーバーヘッドのみを課します。
たとえば、一度に100バイトずつ1 Gbのデータを読み取ります。カーネルはまずそれを512kbの読み取りに変換します。これは最小I / Oサイズであるため（ストライプサイズが512kbの場合）。したがって、次の100バイトはすでにカーネルキャッシュにあります。これは、RAIDではなくパーティションから読み取るのとまったく同じです。
ストライプサイズより小さい書き込みの場合、mdドライバは最初にストライプ全体をメモリに読み込み、メモリを新しいデータで上書きし、結果を計算し（パリティが使用されている場合）（主にRAID 5と6）コピーします。ディスクへの書き込み。
たとえば、一度に100バイトずつ1 Gbのデータを書き込みます。カーネルは最初に512kbのストリップを読み取り、メモリ内の必要な部分を上書きし、パリティが含まれている場合は結果を計算してディスクに書き込みます。次の100バイトを書き込むと、データはカーネルキャッシュにあるため、「512kbストリップの読み取り」のみが防止されます。したがって、メモリを上書きしてパリティを計算するのに多少のオーバーヘッドが発生しますが、データが同じストライプに書き戻されるため、オーバーヘッドが大きくなります。ここのカーネルコードは最適化されていません。
これらの繰り返し書き込みが正しくキャッシュされず、データが数秒後にディスクにフラッシュされる理由を理解するのに十分な調査は行われませんでした（ストライプごとに一度だけ）。キャッシュされた場合、オーバーヘッドは一部のCPUとメモリにすぎませんが、私の独自のベンチマークによると、CPUはまだ10％未満であり、I / Oがボトルネックを引き起こすことがわかりました。
書き込みが最適化されると、最小ストライプサイズは常に最適です。 4つのディスクを備えたRAID 6、4kセクタは8kbストライプを作成し、可能なすべての負荷に対して最高の読み書きスループットになります。
答え3
すべてと同様に、中間点があります。ただし、問題の本質を理解するには、RAID2とRAID3（両方のタイプはほとんど使用されていません）を調べることをお勧めします。
ただし、これは基本的にIOレイテンシと同時データ転送に起因します。各読み取りIO操作には、ヘッドナビゲーションとドライブの回転に数ミリ秒のオーバーヘッドがあります。
データブロックが大きい場合、このペナルティの支払いは少なくなります。これは、より原始的な形式のプリフェッチと非常によく似ています。これらのオーバーヘッドのため、通常、データを要求するときに複数のデータチャンクをプリフェッチすることをお勧めします。統計的にはとにかく必要な可能性が高いからです。
しかし、最も重要なのはショーということです。同調厳密なルールではなく、アクション - ディスクに転送されるワークロードに応じてブロックサイズを設定する必要があります。ワークロードが混在しているかランダムである場合、これを行うことはますます困難になります。ブロックが大きいほどスループットが上がり、IO操作が減ります。通常IO操作はドライブ速度を制限する要因なので通常より大きな需要を作るのに役立ちます。
特定のユースケース（データベースなど）の場合、これは適用されない可能性があります。