2.3. ブロック割り当てにおける問題

本セクションでは、GFS2 ファイルシステムにおけるブロック割り当てに関連した問題の概要を説明します。データの書き込みだけを行うアプリケーションでは通常、ブロックの割り当て方法や割り当て先については問題になりませんが、ブロック割り当ての仕組みを多少理解しておくことにより、パフォーマンスを最適化することができます。

2.3.1. ファイルシステムに空き領域を確保する

GFS2 ファイルシステムがほぼ満杯になると、ブロックアロケーターが割り当てる新規ブロック用の領域を見つけるのが難しくなります。結果として、多くの場合、アロケーターによって割り当てられたブロックはリソースグループの最後または小さいスライス領域に詰め込まれるため、ファイルが断片化する可能性が非常に高くなります。このようなファイルの断片化によって、パフォーマンス上の問題が発生する場合があります。また、GFS2 がほぼ満杯になると、GFS2 のブロックアロケーターが複数のリソースグループを検索するため時間がかかり、十分な空き領域があるファイルシステムでは必ずしも発生しないロック競合が生じます。これにより、パフォーマンス上の問題が発生することがあります。
こういった理由で、 (ワークロードにより数値は変わってきますが) 85% 以上使用済みのファイルシステムを実行しないよう推奨しています。

2.3.2. 可能な場合は各ノードで独自のファイルを割り当てる

全ファイルが単一のノードによって割り当てられて、その他のノードがこれらのファイルにブロックを追加する必要がある場合には、分散ロックマネージャー (DLM) の動作の仕組みが原因となって、ロック競合の発生度が高くなります。
GFS (バージョン 1) では、クラスター全体のロックを制御する中央ロックマネージャーによって全ロックが管理されていました。この Grand Unified Lock Manager (GULM) は単一障害点であったため、問題がありました。GFS2 で置き換えられたロックスキーム DLM は、クラスター全体にロックを分散します。クラスター内のいずれかのノードが停止した場合、そのロックは他のノードによって復旧されます。
DLM では、リソース (ファイルなど) をロックする最初のノードがそのロックの “ロックマスター” となります。その他のノードもリソースをロックすることができますが、その前にロックマスターに許可を求める必要があります。各ノードは、ロックマスターのロックを認識しており、どのノードにロックを貸しているかを認識します。マスターノード以外のノード上のロックをロッキングするには、停止してロックのマスターに許可を求める必要があるため、マスターノード上のロックのロッキングの方がはるかに高速となります。
多くのファイルシステムと同様に、GFS2 のアロケーターは同じファイルのブロックを近くにまとめて、ディスクヘッドの移動を少なくし、パフォーマンスを向上させます。多くの場合、ファイルにブロックを割り当てるノードは、新規ブロック用に同じリソースグループを使用してロックする必要があります (そのリソースグループの全ブロックが使用中である場合を除く)。ファイルが含まれているリソースグループのロックマスターがそのデータブロックを割り当てると、ファイルシステムの動作が高速化します (つまり、ファイルを最初に開いたノードが新規ブロックの書き込みをすべて行うようにした方が動作が高速となります)。

2.3.3. 可能な場合には事前に割り当てる

ファイルが事前割り当て済みの場合、ブロック割り当てを完全に回避して、ファイルシステムの動作を効率化させることができます。GFS2 の新バージョンは、データブロックの事前割り当てに使用できる fallocate(1) システムコールを実装しています。