Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

C.5. Glock-Halter

Tabelle C.5, »Glock-Halter-Flags« zeigt die Bedeutung der verschiedenen Glock-Halter-Flags.

Tabelle C.5. Glock-Halter-Flags

FlagNameBedeutung
aAsyncNicht auf das Glock-Ergebnis warten (Ergebnis wird später abgerufen)
AAnyJeder kompatible Sperrmodus ist zulässig
cNo cacheWenn nicht gesperrt, sofort DLM-Sperre herabstufen
eNo expireNachfolgende Anfragen zur Aufhebung der Sperre ignorieren
EExactMuss den exakten Sperrmodus haben
FFirstGesetzt, wenn der Halter der Erste ist, dem diese Sperre gewährt wird
HHolderZeigt an, dass die angeforderte Sperre gewährt wird
pPriorityReiht Halter an der Spitze der Warteschlange ein
tTryEine „try“-Sperre
TTry 1CBEine „try“-Sperre, die einen Callback sendet
WWaitGesetzt, 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.