PROGETTAZIONE

Ipotesi
Google File System (GFS) stato progettato e realizzato per soddisfare le esigenze di Google
relativamente allelaborazione dei dati. GFS condivide molti degli obiettivi dei file system
distribuiti precedenti, come prestazioni, scalabilit, affidabilit e disponibilit. Tuttavia ne differisce
per altri aspetti.
Si riportano le ipotesi che hanno guidato la progettazione di GFS considerando la tipologia di
applicazioni che lo utilizzano.
Il sistema costruito da commodity hardware economico spesso soggetto a fallimento. Si
deve effettuare costantemente il monitoraggio e operazioni di recupero dai guasti dei
componenti.
Il sistema memorizza un certo numero di file di grandi dimensioni, dellordine dei MultiGB. Ci si pone lobiettivo di supportare anche file di piccole dimensioni anche se non ne
sono state fatte delle ottimizzazioni.
possibile prevedere principalmente due tipi di letture: large streaming reads e small
random reads. Con le large streaming reads, con una singola operazione tipicamente si
leggono centinaia di KB, pi comunemente 1 MB o pi. Le operazioni successive da parte
dello stesso client spesso riguardano la lettura di regioni contigue dello stesso file. Con le
small random reads tipicamente si leggono pochi KB.
Si prevedono anche molte scritture sequenziali per fare lappend dei dati ai file. Una volta
scritti, i file sono raramente rimodificati. Sono supportate anche scritture brevi in posizioni
arbitrarie ma per esse non stata prevista unottimizzazione.
Il sistema implementa una tecnica efficiente per consentire a pi client di fare lappend
contemporaneamente sullo stesso file senza bisogno di sincronizzarsi. essenziale che sia
garantita latomicit con il minimo overhead di sincronizzazione.
Avere una larghezza di banda elevata pi importante del ritardo. La maggior parte delle
applicazioni che usano GFS hanno requisiti stringenti per l'elaborazione dei dati, solo poche
hanno requisiti stringenti relativamente al tempo di risposta per una lettura o una scrittura.
Interfaccia
L'interfaccia per il file system fornita da GFS molto semplice, anche se non prevede le API
standard basate su POSIX. I file sono organizzati gerarchicamente in directory e identificati da un
pathname. Supporta le normali operazioni per creare, eliminare, aprire, chiudere, leggere e scrivere
file.
Inoltre, GFS prevede anche le operazioni di snapshot e di record append.
Lo snapshot crea una copia di un file o di una directory.
La Record append consente a pi client di fare lappend dei dati nello stesso file
simultaneamente garantendo al tempo stesso l'atomicit di accodamento per ogni singolo
client.
Architettura
Un cluster GFS costituito da un unico master e chunkservers multipli a cui vi si accede da pi
client, come mostrato nella Figura 1. Ciascuno di questi tipicamente una macchina Linux che
esegue un processo server a livello utente. possibile eseguire sia un chunkserver che un client
sulla stessa macchina.

I file sono suddivisi in chunk di dimensione fissa. Ogni chunk identificato da un id univoco di 64
bit detto chunk handle, il quale viene assegnato dal master allatto della chunk creation.

I chunkservers memorizzano i chunks su dischi locali come per i file di Linux e si occupano della
lettura o della scrittura di chunk data dato un detrminato chunk handle ed un fissato intervallo di
byte. Per l'affidabilit, ogni chunk replicato su pi chunkservers. Di default, si effettuano tre
repliche, anche se gli utenti possono indicare un numero diverso di repliche per diverse tipologie di
file.
Il master conserva tutti i metadati del file system tra cui il namespace, informazioni di controllo per
l accesso, il mapping tra file e chunck, e le attuali posizioni dei chunk.
Esso controlla anche attivit di sistema come la gestione dei chunk lease, la garbage collection di
chunk orfani, e la migrazione dei chunk tra i chunkservers. Il master comunica periodicamente con
ogni chunkserver tramite messaggi di HeartBeat per dargli istruzioni e registrare il loro stato.
I client GFS comunicano con il master e con i chunkservers per leggere o scrivere dati per conto
della applicazione. I client interagiscono con il master per eseguire operazioni sui metadati, ma per
tutte le operazioni sui dati si rivolgono ai chunkservers.
N il cliente n i chunkserver fanno il caching dei dati.
Il meccanismo di caching lato client offrirebbe pochi vantaggi, perch la maggior parte delle
applicazioni considerano file di grandi dimensioni o che hanno un working set troppo grande perch
possa essere memorizzato nella cache. Non avendo la cache si semplifica il client e il sistema
complessivo, eliminando problemi di coerenza della cache (i client fanno per cache dei metadati). I
chunkservers non memorizzano nella cache i dati perch i chunk vengono memorizzati come file
locali e quindi sono trattati considerando le funzionalit di Linux.
Single Master
Avere un unico master ha semplificato enormemente la progettazione e consente al master di
effettuare un buon posizionamento dei chunk e una buona replicazione utilizzando informazioni
globali. Tuttavia, opportuno minimizzare il suo coinvolgimento nelle letture e nelle scritture in
modo tale che non diventi un collo di bottiglia. I client non leggono n scrivono mai dati attraverso
il master. Bens, un client richiede al master qual il chunkservers che dovrebbe contattare.
Dopodich effettua il cache di queste informazioni (per un tempo limitato per) e interagisce poi
direttamente con il chunkservers per eseguire le operazioni successive.
Discutiamo le interazioni richieste per effettuare unoperazione di lettura con riferimento alla figura
1.

Innanzitutto, usando un chunk size fisso, il client traduce il nome del file e i byte di offset
specificati dallapplicazione in un chunk index all'interno del file. Poi, invia al master una
richiesta contenente il nome del file e il chunk index.
Il master risponde con il corrispondente chunk handle e le posizioni delle repliche.
Il client memorizza queste informazioni utilizzando il nome del file e il chunk index come
chiave.
Il client quindi invia una richiesta ad una delle repliche, probabilmente la pi vicina. La
richiesta specifica il chunk handle e lintervallo dei byte all'interno del chunk. Ulteriori
letture dallo stesso chunk non richiedono pi interazioni client-master finch le informazioni
memorizzate nella cache non scadono o il file non viene riaperto. Infatti, il client richiede
tipicamente informazioni per pi chunk nella stessa richiesta e il master pu anche includere
le informazione di chunk immediatamente successivi a quelli richiesti. Queste informazioni
supplementari evitano il sostenimento di un costo aggiuntivo legato ad interazioni future tra
client-master.

Chunk Size
Il chunk size scelto pari a 64 MB, che molto pi grande rispetto alla dimensione dei blocchi nei
file system tipici. Ogni chunk replica viene memorizzata come un normale file di Linux su di un
chunkserver.
Luso di chunk size grandi offre diversi vantaggi.
In primo luogo, esso riduce la necessit dei client di interagire con il master perch letture e
scritture sullo stesso chunk richiedono ununica richiesta iniziale per recuperare
informazioni sul chunk location. Per le applicazioni che usano GFS questo particolarmente
significativo perch esse leggono e scrivono per lo pi file di grandi dimensioni
sequenzialmente. Anche per letture casuali brevi, il client memorizza comunque nella cache
tutte le informazioni di chunk location per chunk consecutivi.
In secondo luogo, poich molto probabile che un client esegua molte operazioni su un dato
chunk, si pu ridurre l'overhead di rete, mantenendo una connessione TCP persistente con il
chunkserver per un periodo di tempo esteso.
In terzo luogo, riduce la dimensione dei metadati memorizzati sul master.
D'altra parte, luso di chunk size grandi ha anche i suoi svantaggi.
Un file di piccole dimensioni consiste in un numero limitato di chunk, forse solo uno. I
chunkservers che memorizza quei chunk pu diventare hot spot se molti client accedono allo
stesso file. Tuttavia, il problema stato risolto replicando tali chunk su pi di 3 chunkserver.
Unaltra potenziale soluzione quella di consentire ai client di leggere i dati da altri client
che hanno gi fatto laccesso.
Metadata
I master memorizzano tre principali tipi di metadati:
il namespace dei file e dei chunk;
la mappatura tra file e chunk;
le posizioni delle repliche di ogni chunk.
Tutti i metadati sono conservati nella memoria del master.
I primi due tipi sono anche resi persistenti poich memorizzati in un Operation log
memorizzato a sua volta sul disco locale del master e replicato su macchine remote.

Utilizzando un log possibile aggiornare lo stato del master in modo semplice, affidabile e
senza rischiare che ci siano inconsistenze in caso di un crash del master.
Il master non memorizza informazioni sui chunk location in modo persistente. Bens, esso
chiede a ciascuno chunkserver i suoi chunk all'avvio del master e ogni volta che un
chunkserver viene aggiunto al cluster.

Memorizzazione dei matadati

Poich i metadati vengono memorizzati in memoria, le operazioni del master sono veloci. Inoltre, il
master periodicamente effettua uno scanning del suo stato per implementare la garbage collection
dei chunk, la replicazione in presenza di chunkserver falliti, e la chunk migration per bilanciare il
carico e lo spazio su disco utilizzato dai chunkservers.
Il master mantiene meno di 64 byte di metadati per ogni 64 MB chunk.
Se necessario per supportare file system ancora pi grandi, possibile anche aggiungere una
memoria ulteriore nel master per immagazzinare i metadati perch il costo derivante sarebbe
minimo rispetto al guadagno in semplicit, affidabilit, prestazioni e flessibilit che ne deriva.
Posizione dei Chunk
Come gi detto il master non tiene traccia in modo permanente dei chunkservers che sono in
possesso di una replica di un determinato chunk. Semplicemente interroga i chunkservers per
ottenere queste informazioni all'avvio. Il master si tiene aggiornato perch continua a controllare il
posizionamento dei chunk e monitora lo stato dei chunkserver utilizzando messaggi heartbeat
periodici.
Richiedendo queste informazioni al chunkserver solo allavvio stato eliminato il problema di
mantenere il master e i chunkservers in sincronia per rilevare eventi quali modifica di nomi,
fallimenti e cos via. In un cluster con centinaia di server, questi eventi succedono troppo spesso.
Operation Log
LOperation Log tiene traccia dello storico delle modifiche dei metadati. fondamentale per GFS.
I file e i chunk, cos come le loro versioni, sono tutti univocamente identificati dai tempi logici in
cui sono stati creati.
Le modifiche apportate allOperation log opportuno che non siano visibili ai client finch non
sono persistenti. Per garantire affidabilit opportuno replicare questi log su pi macchine remote e
rispondere a unoperazione richiesta dai client solo dopo aver effettuato il flush del record del log
corrispondente alla richiesta su disco, sia in locale che in remoto.
I master raggruppano diversi log record insieme prima del flush su disco riducendo cos l'impatto
del flushing sulla velocit complessiva del sistema.
Il master ripristina lo stato del suo file system riproducendo il suo Operation log. Per per ridurre al
minimo il tempo di avvio, opportuno mantenere tale file piccolo. Per fare questo il master fa il
checkpoint del suo stato ogni volta che il log cresce oltre una certa dimensione in modo che, allatto
del ripristino, possa recuperare lo stato del suo FS caricando l'ultimo checkpoint da disco locale e
consentendo sempre cos la riproduzione di un numero limitato di record.
Poich la costruzione di un checkpoint pu richiedere un po di tempo, lo stato interno del master
strutturato in modo tale che pu essere creato un nuovo checkpoint senza ritardare larrivo di
mutazioni. Il master fa lo switch ad un nuovo log file e crea il nuovo checkpoint in un thread
separato. Il nuovo checkpoint include tutte le mutazioni prima dello switch. Quando finisce, viene
scritto sul disco sia in locale che in remoto. Per il ripristino dello stato il master necessita solo
dell'ultimo checkpoint e dei file di log successivi ad esso. Checkpoint e file di log vecchi possono

essere liberamente cancellati. Un fallimento durante il checkpointing non pregiudica la correttezza

perch il codice di ripristino rileva e tralascia checkpoint incompleti.
Garanzie di GFS
Le mutazioni dei file (ad esempio, la creazione di file) sono operazioni atomiche. Esse sono gestite
esclusivamente dal master: il lock del namespace garantisce latomicit e la correttezza;
nellOperation log del master definito un ordine totale globale di queste operazioni.
Lo stato della regione di un file dopo una mutazione dei dati influenzato sia dal tipo di
mutazione, sia dallesito della mutazione, sia dalla presenza di mutazioni simultanee
(Tabella 1). Una regione di un file consistent se tutti i client vedranno sempre gli stessi
dati, indipendentemente da quale replica essi leggono.
Una regione defined dopo una mutazione dei dati se consistent e se i client vedranno il
risultato della mutazione nella sua interezza atomicit. Quando una mutazione ha
successo senza interferenze da parte di scritture concorrenti, la regione interessata defined
(e implicitamente consistent): tutti i client vedranno sempre quello che la mutazione ha
scritto.
Il successo di mutazioni concorrenti lascia la regione undefined ma consistent: tutti i client
vedono gli stessi dati, ma ci che ciascuno di essi vede non solo quello che effettivamente
stato scritto solo da ciascuno di essi bens ci che stato scritto da tutti.
Una mutazione failed se lascia la regione in uno stato in-consistent (quindi anche
undefined): diversi client possono vedere dati diversi in momenti diversi.
Si descrive adesso come le applicazioni che usano GFS possano distinguere tra regioni defined e
undefined.
Tra le operazioni di mutazioni di dati ricordiamo le writes e le record append.
Una writes comporta la scrittura dei dati in un file dato un offset nel chunk specificato
dallapplicazione.
Una record append prevede che lappend sia atomica at-least-once anche in presenza di
mutazioni concorrenti, dato un offset scelto da GFS. (Al contrario, un append "tradizionale"
semplicemente una scritture in un offset che il client ritiene essere la fine corrente del file).
L'offset viene restituito al client e marca l'inizio di una regione defined che contiene il
lappend.
GFS quindi:
- applica le mutazioni a un Chunk nello stesso ordine in tutte le sue repliche;
- utilizza chunk version number per individuare le repliche definite vecchie perch non sono
state interessate dalla mutazione in quanto durante tale operazione il chunkserver era gi.
Le repliche vecchie diventano garbage.
Poich i client fanno il cache delle chunk locations, essi possono leggere da un replica vecchia
prima ancora che l'informazione venga aggiornata. Questo problema limitato dal fatto che
imposta una scadenza alle entry nella cache e dal fatto che alla prossima apertura del file vengono
eliminati dalla cache tutti i chunk per quel file.
GFS identifica eventuali fallimenti dei chunkservers attraverso un handshaking tra il master e tutti i
chunkservers e rileva la corruzione dei dati attraverso il checksumming. Se viene evidenziato un
problema, i dati vengono ripristinati dalle repliche ancora valide. Un chunk pu essere perso in
maniera irreversibile solo se tutte le sue repliche sono state perse. In questo caso le applicazioni
ricevono messaggi di errori piuttosto che dati corrotti.

Implicazioni per le applicazioni

Tutte le applicazioni mutano i file facendo lappend piuttosto che sovrascrivendo rilassando cos i
vincoli di consistenza.
Tipicamente, con una write si genera un file dallinizio alla fine. Si rinomina atomicamente
il file con un nome permanente solo dopo aver scritto tutto, o in seguito a checkpoint
periodici. I checkpoint possono anche includere checksums a livello di applicazione. I
lettori elaborano solo la regione di file che stata sottoposta all'ultimo checkpoint, la quale
per tanto sar in uno stato defined.
Lappend molto pi efficiente e resistente ai guasti delle random writes.
I reader gestiscono anche leventuale padding e i duplicati. Ogni record contiene informazioni
extra, come il checksum in modo che se ne possa verificare la sua validit. Un reader pu
individuare e scartare il padding extra e i duplicati grazie al checksum.
INTERAZIONI DI SISTEMA
Si vuole ridurre al minimo il coinvolgimento del master nelle le operazioni. Per tanto ora si descrive
come interagiscono il client, il master, e i chunkservers per attuare mutazioni dei dati, record
append e lo snapshot.
Lease e ordinamento delle mutazioni
Una mutazione un'operazione che cambia il contenuto o i metadati di un chunk come le write o le
record append. Ogni mutazione viene eseguita in tutte le repliche del chunk.
Usiamo messaggi di lease per mantenere un ordine di esecuzione delle mutazioni che sia coerente
per le repliche.
Il master invia un chunk lease ad una delle repliche, che noi chiamiamo primary.
Tutte le repliche seguono questo ordine quando eseguono le mutazioni. Il meccanismo di lease
stato progettato per ridurre al minimo loverhead del master. Un lease ha un timeout iniziale di 60
secondi. Tuttavia, la primary replica pu richiedere e ricevere dal master dei prolungamenti ai 60
secondi, richieste che sono piggyback sui messaggi Heartbeat scambiati tra il master e tutti i
chunkservers. Il master pu revocare il lease se il timeout scade. Anche se il master perde la
comunicazione con la primary, pu tranquillamente concedere un nuovo lease a un'altra replica
dopo che il vecchio lease scade.
In Figura 2, illustriamo questo processo con riferimento al flusso di controllo di una scrittura:
1. Il client chiede al master quale chunkserver detiene il lease per il chunk e le posizioni delle
altre repliche. Se non dispone di un lease, il master ne concede uno ad una replica che
sceglie (non mostrato).

2. Il master risponde fornendo l'identit della primary replica e le posizioni delle altre repliche.
Il client memorizza nella cache questi dati per mutazioni future. In questo modo contatter
nuovamente il master solo quando la primary diventa irraggiungibile o risponde che non ha
pi il lease.
3. Il client invia i dati a tutte le repliche in qualsiasi ordine. Ogni chunkserver memorizzer i
dati in un buffer interno finch sono usati e validi.
4. Quando tutte le repliche hanno inviato lack in risposta alla ricezione del dati, il client invia
una richiesta di scrittura alla primary. La primary assegna un serial number consecutivo a
tutte le mutazioni che riceve, possibilmente da pi client, a cui fornisce la necessaria
serializzazione. Esegue poi le mutazioni seguendo questo ordine.
5. La primary inoltra la richiesta di scrittura a tutte le altre repliche. Ogni replica secondaria
esegue le mutazioni nello stesso ordine definito dalla primary.
6. Le repliche secondarie rispondono alla primary indicando di aver completato l'operazione.
7. La primary risponde al client. Eventuali errori sono segnalati al client. Se la scrittura viene
eseguita con successo solo dalla primary e da un sottoinsieme arbitrario delle secondarie (se
fosse fallito la primary, non sarebbe stato definito nessun ordine per poi essere trasmesso) la
richiesta del client si considera fallita e la regione modificata viene lasciata in uno stato
incoerente. I client gestiscono tali errori.
Se una scrittura dall'applicazione grande o supera il limite di un chunk, il client GFS richieder
pi operazioni di scrittura.

Data flow
stato disaccoppiato il flusso dei dati dal flusso di controllo per utilizzare la rete in modo
efficiente. Mentre il flusso di controllo va dal client alla primary e poi a tutte le secondarie, il flusso
dei dati rivolto verso i chunkservers. Lobiettivo quello di sfruttare appieno la banda, evitare i
bottlenecks e ridurre la latenza per linvio dei dati.
Per sfruttare appieno la banda della rete, il flusso dei dati viene propagato linearmente lungo
una catena di chunkservers.
Per evitare colli di bottiglia della rete, per quanto possibile, ogni macchina inoltra i dati alla
macchina "vicina" nella rete che non lha ricevuta ancora. Supponiamo che il client deve
inviare i dati ai chunkservers da S1 a S4. Esso invia i dati al chunkserver pi vicino, ad
esempio S1. S1 propaga ad S2 tramite S4 che pi vicino ad S1 rispetto ad S2. Le distanze
possono essere stimate con precisione considerando gli indirizzi IP delle macchine.
Infine, riduciamo al minimo la latenza canalizzando i dati su connessioni TCP.
Record Append atomiche
GFS fornisce un'operazione di append atomica.
In una record append, come gi detto, il client specifica solo i dati e GFS effettua lappend al file ad
un offset scelto da GFS at-least-once e atomicamente. Tale offset restituito al client.
La record append fortemente utilizzata dalle applicazioni distribuite che usano GFS in cui molti
client su macchine diverse fanno lappend sullo stesso file contemporaneamente. I client avrebbero
bisogno di una sincronizzazione addizionale e costosa, per esempio attraverso Lock Manager
distribuiti, se lo facessero con scritture tradizionali.
La record append prevede le seguenti operazioni.
Il client invia i dati a tutte le repliche che vuole facciano lappend e poi invia la sua richiesta
alla primary.
La primary controlla lappend al chunk corrente potrebbe causarne il superamento della
dimensione massima (64 MB).
- Se cos, aggiunge dei bit di pad al nuovo chunk per riempirlo, dice alle secondarie
di fare lo stesso, e risponde al client che indica che l'operazione deve essere ripetuta
sul prossimo chunk.
- Se lappend non sfora i limiti del chunk (caso pi comune) la primary fa lappend dei
dati su se stessa, dice alle secondarie loffset dove fare lappend e finalmente
risponde con successo al client.
Se la record append fallisce in ogni replica, il client ritenta l'operazione. GFS non garantisce che
tutte le repliche sono identiche. Si garantisce solo che i dati vengono scritti at-least-once
atomicamente.
Snapshot
L'operazione di snapshot crea una copia di un file o di una directory quasi istantaneamente,
minimizzando il tempo di interruzione di eventuali mutazioni in corso. I nostri utenti lo usano per
creare rapidamente copie di grandi insiemi di dati (e spesso copie di copie, ricorsivamente), o per
fare il checkpoint dello stato corrente del master.
Come AFS [5], usiamo la tecnica standard di copy-on-write per fare lo snapshot.
Quando il master riceve una richiesta di snapshot:

prima revoca eventuali lease sui chunk nel file interessato allo snapshot. Questo assicura che
qualsiasi scrittura successiva a questi chunk richiede un'interazione con il master per trovare
il lease. In questo modo il master potr creare una nuova copia del chunk.
Dopo che il lease stato revocato, il master registra in un file i metadati per il file di cui fare
lo snapshot.

Il file di snapshot creato punta agli stessi chunk del file sorgente.
La prima volta che un client vuole scrivere in un chunk C dopo l'operazione di snapshot del file che
contiene C,invia una richiesta al master per individuare il lease corrente.
Il master rileva che il numero dei riferimenti per il chunk C maggiore di uno. Per tanto non
risponde subito al client con lhandle di C bens crea un nuovo chunk handle C.
Chiede quindi ad ogni chunkserver che ha una replica corrente di C di creare un nuovo
chunk chiamato C'. Con la creazione del nuovo chunk sugli stessi chunkservers
dell'originale, si garantisce che i dati possono essere copiati localmente, senza
sovraccaricare la rete.
Da questo punto in poi il master dar il lease per il nuovo chunk C e il client non percepisce
alcuna differenza.
FUNZIONAMENTO MASTER
Il master esegue tutto il namespace. In aggiunta, gestisce le repliche dei chunk per tutto il sistema:
prende decisioni di collocamento, crea nuovi chunk e, quindi repliche, e coordina varie attivit a
livello di sistema per tenere dei chunk completamente replicati, per bilanciare il carico in tutti i
chunkservers, e per recuperare memoria inutilizzata. Ora si discute ciascuno di questi argomenti.
Namespace Management e Locking
Alcune operazioni fatte dal master possono richiedere molto tempo e non vogliamo ritardare altre
operazioni mentre queste sono in esecuzione. Pertanto, possibile consentire a pi operazioni di
essere attive usando i lock per assicurare la corretta serializzazione.
A differenza di molti file system tradizionali, GFS non ha una struttura dati a directory che elenca
tutti i file in quella directory. N supporta gli alias per lo stesso file o directory (ad esempio,
collegamenti fisici o simbolici, in termini di Unix). GFS rappresenta logicamente il suo namespace
come una tabella di lookup che contiene tutti i pathname e i relativi metadati.
Ogni nodo nel namespace (un nome assoluto di file o un nome assoluto di directory) ha un lock di
lettura-scrittura associato. Ogni operazione del master acquisisce un insieme di lock prima di essere
eseguita. In genere, se coinvolge / d1/d2/.../dn/leaf, sar acquisito un read lock sui nomi delle
directory / d1, / d1/d2, ..., / D1/d2/.../dn, e un read lock o un write lock sul percorso completo /
d1/d2/.../dn/leaf. Si noti che leaf pu essere un file o una directory a seconda dell'operazione.
Ora illustriamo come questo meccanismo di locking pu impedire che venga creato un file / home /
user/foo, mentre viene fatto lo snapshot di /home/utente su /save/user.
L'operazione di snapshot acquisisce:
- un read lock su /home e /save
- un write lock su /home /user e /save/user.
La file creation acquisisce:
- un read lock su /home e /home/user
- un write lock su /home/user/foo.

Le due operazioni saranno serializzate correttamente perch cercano di ottenere lock contrastanti su
/home/user. La file creation non richiede un write lock sulla directory principale perch non c' una
struttura dati a "directory da proteggere da modifiche.
Il read lock sufficiente per proteggere la parent directory dall'eliminazione.
Una buona propriet di questo schema di locking che permette mutazioni concorrenti nella stessa
directory.
Per esempio, possibile eseguire sulla stessa directory contemporaneamente diverse file creation:
ognuna acquisisce un read lock sul nome della directory e un write lock sul nome del file.
sufficiente un read lock sul nome della directory per evitare che la directory sia cancellata,
rinominata o snapshotted. I write lock sul nome dei file serializza i tentativi di creare un file con lo
stesso nome due volte.
I lock vengono acquisiti in un ordine totale e coerente per evitare deadlock: vengono prima ordinati
per livello nellalbero di namespace e lessicograficamente all'interno dello stesso livello.
Replica Placement
Un cluster GFS ha in genere centinaia di chunkservers sparsi su molti rack. Questi chunkservers a
loro volta possono essere acceduti da centinaia di client da stessi o diversi rack. La comunicazione
tra due macchine su diversi rack pu attraversare uno o pi switch di rete. Inoltre, la larghezza di
banda all'interno o all'esterno di un rack pu essere inferiore alla larghezza di banda aggregata di
tutte le macchine all'interno del rack.
La politica di posizionamento delle repliche dei chunk serve a due scopi:
massimizzare l'affidabilit e la disponibilit dei dati;
massimizzare lutilizzo della banda.
Per tanto, dobbiamo distribuire le chunk replica anche tra i rack. Questo assicura che alcune
repliche di un chunk rimangono disponibili anche se un intero rack viene danneggiato o spento.
Significa anche che il traffico, soprattutto per le letture sfrutta la banda di pi rack aggregati.
D'altra parte per, il traffico delle scritture deve coinvolgere pi rack.
Creazione, Re-replication, Rebalancing
Le chunk repliche sono create per tre motivi:
creazione. Quando il master crea un chunck, sceglie dove posizionare le repliche
considerando i seguenti fattori.
(1) Vogliamo posizionare nuove repliche sui chunkservers che hanno pi spazio libero su
disco.
(2) Vogliamo limitare il numero di creation "recenti" su ogni chunkserver.
(3) Come discusso sopra, vogliamo distribuire le repliche dei chunk su rack diversi.
ri-replicazione. Il master ri-replica un chunk appena il numero di repliche disponibili scende
sotto un valore specificato dall'utente (replication goal). Questo potrebbe accadere per vari
motivi: un chunkserver non pi disponibile, una chunk replica potrebbe essere
danneggiata, o il replication goal aumentato. Ad ogni chunk che necessita di essere rireplicato associata una priorit in base a diversi fattori. Uno di questi fattori la distanza
dal raggiungimento del suo replication goal. Infine, per minimizzare l'impatto dei guasti
sulle applicazioni in esecuzione, dobbiamo aumentare la priorit di qualsiasi chunk che
blocca il progresso dei client. Il master prende il chunk a priorit pi alta e lo "clona"
istruendo alcuni chunkserver per copiare i dati del chunk direttamente da una replica valida
esistente.

Per evitare che il traffico del client sia travolto dal traffico di clonazione, il master limita il
numero di operazioni clone attive.
rebalancing. Il master fa il rebalancing delle repliche periodicamente: esamina la
distribuzione corrente delle repliche e sposta le repliche per ottimizzare lutilizzo dello
spazio su disco e per il bilanciamento del carico. Inoltre, il master deve anche scegliere
quale replica esistente deve rimuovere. In generale, si preferisce rimuoverle da quei
chunkservers che hanno poco spazio libero.

Garbage Collection
Dopo che un file viene eliminato, GFS non consente di recuperare subito la memoria fisica liberata.
Tutto questo per rendere il sistema pi affidabile.
Meccanismo
Quando un file viene cancellato dall'applicazione, il master registra la cancellazione proprio come
fa con le altre modifiche. Tuttavia invece di liberare le risorse immediatamente il file viene solo
rinominato con un nome nascosto. In seguito, durante la scansione regolare del namespace, rimuove
questi file nascosti se sono rimasti in questo stato per pi di tre giorni (l'intervallo configurabile).
Fino ad allora, il file pu ancora essere letto utilizzando il nome nascosto ma non pu essere
rinominato con il vecchio nome.
Quando il file nascosto viene rimosso dal namespace, i suoi metadati vengono cancellati. Questo
fatto su tutte le repliche.
Durante la scansione regolare del namespace, il master identifica i chunk orfani (cio quelli non
raggiungibili da nessun file) e cancella i metadati per essi. Nei messaggi di HeartBeat regolarmente
scambiati con il master, ogni chunkserver elenca un sottoinsieme dei chunk che ha, e il master
risponde con l'identit di tutti i chunk che non sono pi presenti nei metadati del master. Il
chunkserver potr ora cancellare le repliche di questi chunk.
Discussione
Possiamo identificare facilmente tutti i riferimenti ai chunk: essi sono mantenuti esclusivamente dal
master.
Possiamo anche identificare facilmente tutte le chunk repliche: sono File Linux sotto directory
assegnate su ogni chunkserver. Qualsiasi replica non nota al master "garbage".
Il fatto di ritardare il rilascio della memoria offre diversi vantaggi rispetto alla cancellazione
immediata.
In primo luogo, semplice ed affidabile in un sistema distribuito su larga scala in cui i
guasti dei componenti sono comuni. I messaggi di cancellazione delle repliche potrebbero
essere persi, e il master deve ricordarsi di inviarli nuovamente in seguito a fallimenti sia
propri che dei chunkserver. La garbage collection offre un modo uniforme e affidabile per
cancellare eventuali repliche non pi utili.
In secondo luogo, colloca le attivit di ripristino dello spazio della memoria tra le attivit
svolte in backgroud dal master, come la scansione regolare del namespace e lhandshake con
i chunkservers e quindi se ne ammortizza il costo. Inoltre, vengono eseguite solo quando il
master relativamente libero. In questo modo il master pu rispondere pi rapidamente alle
richieste dei client che richiedono attenzioni tempestive.
In terzo luogo, il ritardo nel ripristino dello spazio della memoria fornisce maggiore
sicurezza contro cancellazioni accidentali.
Lo svantaggio principale dato proprio dal ritardo relativo al ripristino dello spazio di memoria.

Stale Replica Detection

Le chunk replica possono diventare vecchie se in seguito ad un fallimento del chunkserver non
ricevono la richiesta di esecuzione di mutazioni su di un chunk. Per ogni chunk, il master mantiene
un chunk version number per distinguere repliche vecchie da quelle aggiornate.
Ogni volta che il master concede un nuovao lease su di un chunk, incrementa il chunk version
number e informa le repliche dellaggiornamento. Il master e queste repliche registrano il nuovo
chunk version number in modo permanente. Questo avviene prima che il client informato e quindi
prima che possa cominciare la scrittura sul chunck. Se un'altra replica correntemente non
disponibile, non sar incrementato il suo chunk version number. Il master rilever che questo
chunkserver ha una replica vecchia quando il chunkserver viene riavviato ed elenca i suoi chunk e
relativi chunk version number associati.
Il master rimuove le repliche vecchie usando lalgoritmo classico di garbage collection. Inoltre il
master include il chunk version number quando informa i client su quale chunkserver detiene un
lease su un chunk o quando istruisce un chunkserver per leggere chunk da un altro chunkserver in
una operazione di clonazione. Il client o il chunkserver verificano il numero di versione quando
eseguono l'operazione in modo che accedono sempre ai dati aggiornati.
Tolleranza ai guasti e DIAGNOSI
La qualit e la quantit dei componenti su cui si basa GFS fanno si che i fallimenti siano pi la
norma che l'eccezione. Si discute ora di com possibile affrontare questa problematica.

High Availability. Tra le centinaia di server di un cluster GFS, alcuni sono destinati ad
essere disponibili in qualsiasi momento. possibile mantenere il sistema globale altamente
disponibile utilizzando due semplici ma efficaci strategie:
- Fast recovery. Sia il master che i chunkserver sono progettati per poter ripristinare il
loro stato.
- Replica Chunk. Come discusso in precedenza, ogni chunk replicato su pi
chunkservers su diversi rack. Gli utenti possono specificare differenti livelli di
replicazione per i diversi chunk del namespace. Il valore predefinito tre. Il master
clona repliche esistenti quando necessario per mantenere ogni chunk completamente
replicato.
Replicazione del master. Lo stato del master viene replicato per l'affidabilit. Il suo
operation log e checkpoint vengono replicati su pi macchine. Per semplicit per, un unico
processo master rimane responsabile di tutte le mutazioni, nonch di attivit di background
come la garbage collection che cambiano il sistema internamente. Quando fallisce, pu
essere riavviato quasi istantaneamente. Se per il fallimento dovuto allhardware o al
disco, uninfrastruttura di monitoraggio esterna a GFS avvia una nuovo processo master con
operation log replicato. I client utilizzano un nome canonico del master (ad esempio gfstest), che un alias DNS che pu essere cambiato se il master trasferito su un'altra
macchina. Inoltre, ci sono anche shadow master che forniscono accesso in sola lettura al
file system, anche quando il master primario gi. Poich il contenuto del file viene letto
dai chunkservers, le applicazioni non osservano mai del contenuto vecchio. Potrebbero
essere per vecchi i metadati del file. Per essere aggiornati, gli shadow master leggono una
replica delloperation log e applicano la stessa sequenza di modifiche alla loro struttura dati
esattamente come fa il master primario. Come il master primario, all'avvio interrogano i
chunkservers per individuare le chunk repliche e scambiano frequenti messaggi di
handshake con loro per monitorare il loro stato. Dipendono dal master primario solo per

laggiornamento delle posizioni delle repliche derivanti dalle decisioni del master primario
di creare ed eliminare le repliche.
Integrit dei dati. Ogni chunkserver utilizza il checksum per rilevare la corruzione dei dati
memorizzati. Dato che un cluster GFS ha spesso migliaia di dischi su centinaia di macchine,
sperimenta regolarmente fallimenti sui dischi che causano il danneggiamento dei dati. Non
conviene risolvere il problema utilizzando altre chunk replica perch potrebbero comunque
essere divergenti: la semantica di mutazioni GFS, in particolare le record append atomiche,
non garantisce di avere repliche identiche. Pertanto, ogni chunkserver deve verificare
autonomamente l'integrit della propria copia mantenendo dei checksum. Un chunk
suddiviso in 64 KB blocchi. Ciascuno ha un checksum corrispondente a 32 bit. Come per gli
altri metadati, i checksum sono tenuti in memoria e memorizzati in modo persistente. Per le
letture, il chunkserver verifica il checksum dei blocchi dei dati prima di restituire i dati al
richiedente, sia esso un client o un altro chunkserver. Pertanto i chunkservers non propagano
corruzioni a altre macchine. Se per un blocco il cheksum non corrisponde a quello registrato,
il chunkserver restituisce un errore al richiedente e segnala la mancata corrispondenza al
master. In risposta, il richiedente legger da altre repliche, mentre il master cloner il chunk
da un'altra replica. Dopo aver effettuato la clonazione, il master istruisce il chunkserver che
ha segnalato la mancata corrispondenza a cancellare la sua replica. Il calcolo del checksum
particolarmente ottimizzato per le append (al contrario delle write), perch sono le
operazioni pi comunemente utilizzate dalle applicazioni che fanno uso di GFS. Abbiamo
appena incrementale Aggiorniamo semplicemente in modo incrementale il ckecksum per
lultimo blocco. Al contrario, se facciamo una write, dobbiamo leggere e verificare il primo
e l'ultimo blocco del range da sovrascrivere, quindi eseguire la scrittura e infine calcolare e
registrare i nuovi checksum. Se non facciamo la verifica del primo e dell'ultimo blocco
prima della loro sovrascrittura, i nuovi checksum possono nascondere corruzione nelle
regioni che non vengono sovrascritte. Durante i periodi di inattivit, i chunkservers possono
eseguire la scansione e verificare il contenuto dei blocchi inattivi. Questo ci permette di
rilevare corruzioni in chunck che raramente leggono. Una volta che la corruzione rilevata,
il master pu creare una nuova replica e cancellare la replica danneggiata. Ci impedisce
che una chunk replica inattiva ma danneggiato faccia in modo che il master pensi che ha
abbastanza repliche valide di un chunck.