2.9. Blocco dei nodi GFS2
Per ottenere le migliori prestazioni da un file system GFS2 è importante comprendere alcune delle teorie operative di base. Un file system con un solo nodo viene implementato insieme ad una cache, tale operazione serve per eliminare la latenza presente a causa dell'accesso al disco quando si utilizzano frequentemente determinati dati. Con Linux il page cache (ed il buffer cache) forniscono queste funzioni di caching.
Con GFS2 ogni nodo presenta la propria page cache la quale può contenere alcune porzioni di dati sul-disco. GFS2 utilizza un meccanismo di bloccaggio chiamato glocks per mantenere l'integrità della cache tra i nodi. Il sistema secondario di glock fornisce una funzione di gestione della cache implementata tramite il distributed lock manager (DLM) come livello di comunicazione sottostante.
Glock fornisce una protezione per la cache per ogni inode, in questo modo è presente un blocco per inode usato per controllare il caching. Se si conferisce glock in modalità condivisa (DLM lock mode: PR) i dati presenti nel glock in questione potranno essere archiviati contemporaneamente su uno o più nodi, in questo modo tutti i nodi potranno avere un accesso locale ai dati.
Se si conferisce glock in modalità esclusiva (DLM lock mode: EX) allora solo un unico nodo potrà archiviare i dati in cache sotto il glock in questione. Questa modalità viene usata da tutte le operazioni che modificano i dati (come ad esempio una chiamata del sistema
write).
Se un altro nodo richiede un glock, il quale a sua volta non potrà essere immediatamente conferito, DLM invia un messaggio al nodo o nodi che attualmente presentano un glock i quali bloccano la nuova richiesta, richiedendone il loro rilascio. Il rilascio di glock (in base agli standard di numerose operazioni del file system) è una operazione molto lunga. Il rilascio di un glock condiviso richiede la sola rimozione della convalida della cache, tale processo è relativamente veloce e proporzionale alla quantità di dati archiviati in cache.
Il rilascio di un glock esclusivo richiede un processo di azzeramento molto lungo e di riscrittura dei dati modificati sul disco, il tutto seguito dalla rimozione della convalida simile al glock condiviso.
La differenza presente tra un file system con un solo nodo e GFS2 è che il primo presenta una cache singola mentre il secondo (GFS2) presenta una cache separata su ogni nodo. In entrambi i casi la latenza per l'accesso ai dati archiviati in cache è simile, ma la latenza per l'accesso ai dati non archiviati in cache è maggiore in GFS2 se un altro nodo ha precedentemente archiviato gli stessi dati.
Nota
A causa del metodo usato per l'implementazione del caching di GFS2 le migliori prestazioni si ottengono quando:
- Un inode viene usato in sola lettura su tutti i nodi.
- Un inode viene scritto o modificato solo da un nodo singolo.
Da notare che l'inserimento e la rimozione delle voci da una directory durante la creazione e la cancellazione di un file conta come la scrittura sull'inode della directory.
È possibile non rispettare questa regola se la stessa viene generalmente osservata. Se la regola spesso non viene rispettata l'utente andrà incontro a problemi molto seri di prestazione.
Se eseiguite il
mmap() di un file su GFS2 con una mappatura lettura/scrittura, ma eseguite solo la lettura, tale operazione conta solo come lettura. Al contrario su GFS l'operazione conta come scrittura, in questi termini GFS2 è molto più scalabile con mmap() I/O.
Se non impostate il parametro
noatime mount, allora i processi di lettura causeranno l'aggiornamento dei timestamp del file anche da parte del processo di scrittura. È consigliato a tutti gli utenti di GFS2 di eseguire il montaggio usando noatime a meno che non siano presenti requisiti specifici per atime.
2.9.1. Problematiche con il Posix Locking
Prima di utilizzare Posix locking considerate quanto di seguito riportato:
- L'uso di Flocks permette di avere una processazione più veloce rispetto ai lock di Posix.
- I programmi che utilzzano i lock di Posix in GFS2 non devono utilizzare la funzione
GETLK, poichè in un ambiente clusterizzato l'ID del processo potrebbe essere per un nodo diverso nel cluster.
