Red Hat Training

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

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.

Tabella C.1. Modalità glock e DLM lock

Modalità glockModalità DLM lockNote
UNIV/NLUnlocked (nessun DLM lock associato con glock o con NL lock in base al flag I)
SHPRLock condiviso (lettura protetta)
EXEXLock esclusivo
DFCWPosticipato (scrittura simultanea) isato per I/O Diretto e per la sospensione del file system
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.

Nota

Questo aspetto particolare del comportamento di DLM lock è diverso da quello in Red Hat Enterprise Linux 5, il quale talvolta sbloccava i DLM lock assegnati ai glock, per questo motivo Red Hat Enterprise Linux 5 ha un meccanismo diverso per assicurare che i LVB (lock value block) siano preservati quando necessario. Il nuovo schema usato da Red Hat Enterprise Linux 6 è stato reso possibile grazie all'unione del modulo lock lock_dlm (da non confondere con DLM stesso) con GFS2.
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.

Nota

Workqueue hanno i propri tracepoint i quali possono essere usati insieme con i tracepoint di GFS2 se desiderato
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.

Tabella C.2. Tipi di dati e modalità di glock

Modalità glockDati della cacheMetadati della cacheDati corrottiMetadati corrotti
UNNoNoNoNo
SHSiSiNoNo
DFNoSiNoNo
EXSiSiSiSi