C.5. Glock-Halter
Tabelle C.5, »Glock-Halter-Flags« zeigt die Bedeutung der verschiedenen Glock-Halter-Flags.
| Flag | Name | Bedeutung |
|---|---|---|
| a | Async | Nicht auf das Glock-Ergebnis warten (Ergebnis wird später abgerufen) |
| A | Any | Jeder kompatible Sperrmodus ist zulässig |
| c | No cache | Wenn nicht gesperrt, sofort DLM-Sperre herabstufen |
| e | No expire | Nachfolgende Anfragen zur Aufhebung der Sperre ignorieren |
| E | Exact | Muss den exakten Sperrmodus haben |
| F | First | Gesetzt, wenn der Halter der Erste ist, dem diese Sperre gewährt wird |
| H | Holder | Zeigt an, dass die angeforderte Sperre gewährt wird |
| p | Priority | Reiht Halter an der Spitze der Warteschlange ein |
| t | Try | Eine „try“-Sperre |
| T | Try 1CB | Eine „try“-Sperre, die einen Callback sendet |
| W | Wait | Gesetzt, während auf den Abschluss einer Anfrage gewartet wird |
Die wichtigsten Halter-Flags sind, wie bereits erwähnt, H (holder) und W (wait), da sie auf gewährte Sperranforderungen bzw. in der Warteschlange befindliche Sperranforderungen gesetzt werden. Die Reihenfolge der Halter in der Liste ist wichtig. Wenn es gewährte Halter gibt, werden sie immer an der Spitze der Warteschlange sein, gefolgt von jeglichen wartenden Haltern.
Wenn es keine gewährten Halter gibt, dann wird der erste Halter in der Liste derjenige sein, der die nächste Statusveränderung auslöst. Da Herabstufungsanfragen immer eine höhere Priorität als Anfragen aus dem Dateisystem haben, muss dies nicht immer direkt zu der angeforderten Statusänderung führen.
Das Glock-Subsystem unterstützt zwei Arten der „try“-Sperre. Diese sind hilfreich, weil sie erstens die Entnahme von Sperren außerhalb der normalen Reihenfolge (mit angemessenem Back-off und Wiederholung) ermöglichen, und zweitens bei der Vermeidung von Ressourcen helfen, die von anderen Knoten verwendet werden. Die normale t (try) Sperre ist im Grunde genau wie der Name schon sagt eine „Versuchssperre“, die nichts besonderes macht. Die T (
try 1CB) Sperre ist identisch mit der t-Sperre, mit dem Unterschied, dass der DLM einen einzelnen Callback an die derzeitigen Halter der inkompatiblen Sperre sendet. Ein Anwendungsfall der T (try 1CB) Sperre ist zusammen mit den iopen-Sperren, die verwendet werden, um zwischen den Knoten zu vermitteln, wenn die i_nlink-Anzahl eines Inodes Null ist, um zu bestimmen, welche der Knoten für das Freigeben des Inodes verantwortlich ist. Das iopen-Glock wird normalerweise im gemeinsam verwendeten Status gehalten, wenn jedoch die i_nlink-Anzahl auf Null sinkt und ->delete_inode() aufgerufen wird, fragt es eine exklusive Sperre mit gesetztem T (try 1CB) Flag an. Es wird weiterhin den Inode freigeben, wenn die Sperre gewährt wird. Wenn die Sperre nicht gewährt wird, kennzeichnen die Knoten, die die Gewährung der Sperre verhinderten, ihre Glocks mit dem D (demote) Flag, das beim Zeitpunkt von ->drop_inode() kontrolliert wird, um sicherzustellen, dass die Aufhebung der Zuordnung nicht vergessen wird.
Dies bedeutet, dass Inodes, die eine Linkanzahl von Null haben, aber noch offen sind, durch denjenigen Knoten aufgehoben werden, auf dem das endgültige
close() stattfindet. Zur selben Zeit, wie der Linkzähler des Inodes auf Null gesetzt wird, wird der Inode für den speziellen Status gekennzeichnet, dass dieser zwar die Linkanzahl Null hat, aber immer noch in der Ressourcengruppen-Bitmap im Einsatz ist. Dies ähnelt der Waisenliste (engl: orphan list) im ext3-Dateisystem insofern, als es jedem späteren Leser der Bitmap mitteilt, dass es möglicherweise Platz gibt, der zurückgefordert werden könnte, und diesen dazu auffordert, den Platz zurückzufordern.
