C.5. glock ホルダー

表C.5「Glock holder flags」 には、異なる glock ホルダーのフラグの意味をまとめています。

前述したように、H (holder) および W (wait) はそれぞれ、許可されたロック要求と、キューに追加されたロック要求に設定されるので、最も重要なホルダーフラグです。一覧内でのホルダーの順序付けは重要です。許可されたホルダーがある場合は、必ずキューの先頭に配置され、キューに追加されたホルダーがその後に続きます。

許可されたホルダーがない場合には、一覧の最初のホルダーが次の状態変更をトリガーします。降格の要求は、ファイルシステムからの要求よりも常に優先度が高いとみなされるため、この要求によって必ずしも直接、要求された状態への変更が行われるわけではありません。

glock のサブシステムは、2 種類の "try" ロックをサポートしています。これらのロックは、(適切なバックオフとリエントリで) 通常の規則に反したロックの取得を可能にするのに加えて、他のノードが使用中のリソースを回避するのに役立つので、いずれも有用です。通常の t (try) ロックは、基本的にはその名前の示すとおりの "try" ロックで、特別なことは何もしません。一方、T (Try 1CB) ロックは、DLM が単一のコールバックを互換性のないロックホルダーに送信する点以外は t ロックと同じです。T (Try 1CB) ロックの用途の一つに、iopen ロックとの併用があります。このロックは、inode の i_nlink カウントがゼロの時にノードを判別して、どのノードが割り当て解除の原因となっているかを判断するのに使用します。iopen glock は通常共有の状態で保持されますが、i_nlink カウントがゼロになって ->delete_inode() が呼び出されると、排他的ロックを T (try 1CB) に設定するように要求します。ロックが許可された場合には、inode の割り当て解除を継続します。ロックが許可されない場合には、ロックの許可を阻止しているノードで glock に D (Demote) フラグが付きます。このフラグは、割り当て解除が忘れられないように ->drop_inode() の時にチェックされます。

これは、リンクカウントがゼロでありながら開いている inode が、最終の close() が発生するノードによって割り当て解除されることを意味します。また、inode のリンクカウントがゼロに減少するのと同時に、その inode は、リンクカウントがゼロでありながらもリソースグループビットマップで依然として使用中であるという特別の状態としてマークされます。この関数は、ext3 ファイルシステムの孤立アイテム一覧と同様に、後に続くビットマップのリーダーに、再使用可能な潜在的領域があることを知らせて、再利用を試みます。