C.3. Glocks

Für das Verständnis von GFS2 ist es notwendig, das wichtigste Konzept zu verstehen, das es von anderen Dateisystemen unterscheidet: Das Konzept der Glocks. In Quellcode-Begriffen ist ein Glock eine Datenstruktur, die DLM und Caching in einem Single-State-Rechner vereinigt. Jedes Glock hat eine 1:1-Beziehung mit einer einzigen DLM-Sperre und bietet Caching für diesen Sperrstatus, sodass wiederholt durchgeführte Operationen von einem einzelnen Knoten des Dateisystems nicht immer wieder den DLM aufrufen müssen, was unnötigen Netzwerkverkehr vermeidet. Es gibt zwei wesentliche Kategorien von Glocks: Solche, die Metadaten cachen, und solche, die dies nicht tun. Die Inode-Glocks und die Ressourcengruppen-Glocks cachen beide Metadaten, andere Arten von Glocks cachen Metadaten nicht. Der Inode-Glock cacht darüberhinaus auch Daten und hat von allen Glocks die aufwendigste Logik.

Glocks bleiben im Speicher, bis sie entsperrt werden (auf Anforderung eines anderen Knotens oder auf Anforderung der VM) und es keine lokalen Benutzer gibt. Zu diesem Zeitpunkt werden sie aus der Glock-Hash-Tabelle entfernt und freigegeben. Beim Erstellen eines Glocks wird die DLM-Sperre nicht sofort mit dem Glock verknüpft. Die DLM-Sperre wird bei der ersten Anforderung an den DLM mit dem Glock verknüpft und wenn diese Anforderung erfolgreich ist, dann wird das Flag „I“ (Initial) auf dem Glock gesetzt. Tabelle C.4, »Glock-Flags« zeigt die Bedeutungen der verschiedenen Glock-Flags. Sobald der DLM mit dem Glock verknüpft wurde, verbleibt die DLM-Sperre immer zumindest im Sperrmodus NL (Null), bis das Glock freigegeben wird. Eine Herabstufung der DLM-Sperre von NL auf entsperrt ist immer die letzte Operation im Leben eines Glocks.

Jedem Glock kann eine Reihe von „Haltern“ zugeordnet sein, von denen jeder eine Sperranforderung von den höheren Schichten darstellt. Die Systemaufrufe für GFS2 fügen Halter in die Warteschlange für dieses Glock ein oder entfernen sie daraus, um den kritischen Abschnitt des Codes zu schützen.

Die Glock State Machine basiert auf einer Arbeitswarteschlange. Aus Effizienzgründen wären Tasklets vorzuziehen, aber in der aktuellen Implementierung muss I/O aus diesem Kontext gesendet werden, was deren Verwendung verhindert.

Tabelle C.2, »Glock-Modi und Datentypen« zeigt, welcher ​​Status bei jedem Glock-Modus gecacht werden kann und ob dieser gecachte Status verändert („dirty“) sein darf. Dies gilt sowohl für Inode- als auch für Ressourcengruppen-Sperren, obwohl es keine Datenkomponente für die Ressourcengruppen-Sperren gibt, nur Metadaten.