2.7. ブロック割り当て

GFS2 ファイルシステムがほぼ満杯になると、ブロックアロケーターは、割り当てる新しいブロックの領域の検索をうまく処理できなくなります。その結果、アロケータにより割り当てられたブロックは、リソースグループの最後またはファイルの断片化が発生する可能性が非常に高い小さなスライスに絞り込まれる傾向があります。このファイルの断片化により、パフォーマンスの問題が発生することがあります。また、GFS2 ファイルシステムがほぼ満杯になると、GFS2 ブロックアロケーターは複数のリソースグループを検索するのにより多くの時間を費やし、十分な空き領域があるファイルシステムには必ずしも存在しないロック競合を追加します。また、パフォーマンスの問題が発生する可能性もあります。

こういった理由で、(ワークロードにより数値は変わってきますが) 85% 以上が使用済みのファイルシステムを実行しないことが推奨されます。

GFS2 ファイルシステムで使用するアプリケーションを開発する場合は、可能であれば独自のファイルを各ノードに割り当てることが推奨されます。全ファイルが 1 つのノードにより割り当てられ、その他のノードがこれらのファイルにブロックを追加する必要がある場合には、分散ロックマネージャー (DLM) の動作の仕組みが原因となって、ロック競合が多くなります。

これまでロックマスターという用語を使用して、クラスター内のリモートノードまたはローカルから送信されるロック要求の現在のコーディネーターノードを表していました。ロック要求コーディネーターというこの用語は、ロック要求のキューへの追加、許可または拒否の面からすると実際にはリソース (DLM 用語) を指すので若干誤解を招きます。DLM はピアツーピアシステムであるため、DLM で使用する用語では、リーダーという意味で使用されるべきです。

Linux カーネルの DLM 実装では、ロックを最初に使用するノードが、ロック要求のコーディネーターになり、その時点から、コーディネーターは変更されません。これは、Linux カーネル DLM の実装の説明で、一般的に DLM のプロパティーではありません。今後の更新により、特定のロック要求を連携することでノード間の移行が可能になります。

ロック要求が連携される場所は、ロック要求のイニシエーターに対して透過的です。ただし、要求のレイテンシーからの影響がある場合を除きます。現在の実装で考えられる 1 つの結果として、(I/O コマンドを実行する他のノードよりも前に、1 つのノードがファイルシステム全体をスキャンする場合など) 最初のワークロードでバランスが取れていない場合に、ファイルシステムを最初にスキャンしたノードと比べると、クラスター内の他のノードのロックでレイテンシーが発生する可能性が高くなります。

多くのファイルシステムと同様、GFS2 アロケーターは、ディスクヘッドの動きを抑え、パフォーマンスを向上させるために、同じファイルのブロックを互いに近づけようと試みます。ブロックをファイルに割り当てるノードは、新しいブロックに同じリソースグループを使用してロックする必要があります (そのリソースグループ内のすべてのブロックが使用中の場合を除きます)。ファイルを含むリソースグループのロック要求コーディネーターがデータブロックを割り当てると、ファイルシステムの実行が速くなります (ファイルを最初に開いたノードが新しいブロックの全書き込みを実行する方が速くなります)。

ファイルを事前に割り当てた場合は、ブロックの割り当てを完全に回避し、ファイルシステムをより効率的に実行できます。GFS2 には、fallocate(1) システムコールが含まれます。これは、データブロックの割り当てに使用できます。