C.3. Glock

Per capire meglio GFS2 è importante comprendere il concetto più significativo, e quello che lo rende diverso da altri file system, e cioè il concetto di glock. In termini di codice sorgente un glock rappresenta una struttura dati che raggruppa DLM e la memoria in cache in una sola macchina. Ogni glock ha un rapporto di 1:1 con un DLM lock singolo, e fornisce la memoria in cache per il relativo stato, così facendo le operazioni ripetitive eseguite da un singolo nodo del file system non invocano ripetutamente DLM, limitando così il traffico non necessario di rete. Sono presenti due categorie di glock, quelli che salvano i dati in cache e quelli che non eseguono questa operazione. Gli inode glock e i glock del gruppo di risorse eseguono il salvataggio in cache dei metadati, altri tipi di glock non eseguono questa operazione. L'inode glock può eseguire entrambe le operazioni di salvataggio dei dati e metadati in cache, e presenta la logica più complessa tra tutti i glock.

Glock è in grado di restare in memoria fino a quando non vengono sbloccati (per la richiesta di un altro nodo o di una VM) e non sono presenti utenti locali. A quel punto essi verranno rimossi dalla tabella hash di glock e resi disponibili. Al momento della creazione di un glock il DLM lock non verrà immediatamente associato. DLM lock viene associato con glock previa prima richiesta ricevuta da DLM, e se la richiesta ha avuto successo, il flag "I" (iniziale) verrà impostato su glock. Tabella C.4, «Flag di glock» mostra i significati dei diversi flag di glock. Dopo aver eseguito l'associazione il DLM lock avrà sempre, come minimo, una modalità di NL (Null) fino a quando non si libererà glock. Un declassamento di DLM lock da NL a unlocked, è sempre l'ultima operazione nel ciclo di vita di glock.

Ogni glock può avere un certo numero di "holder" ad esso associati, ognuno dei quali rappresenta una richiesta di lock dai livelli superiori. Le invocazioni del sistema relative al GFS2, mettono in coda (o rimuovono) gli holder dal glock per proteggere la sezione critica del codice.

La glock state machine si basa su una workqueue. Per regioni relative alle prestazioni, è preferibile usare tasklet; tuttavia nell'implementazione attuale è necessario inviare I/O dal contesto attuale il quale ne proibisce il loro uso.

Tabella C.2, «Tipi di dati e modalità di glock» mostra lo stato nel quale vengono memorizzati in cache le modalità di glock, indicando anche eventuali errori. Questa operazione riguarda sia i lock del gruppo di risorse che quelli degli inode, anche se non vi è alcun componente dati per i lock del gruppo di risorse, ma solo metadati.