ZFS

Introduzione

L’acronimo ZFS sta per Zettabyte File System in virtù dei suoi limiti teorici dell’ordine di grandezza di Zettabyte.

1 Zettabyte = 1 000 000 000 000 000 000 000 Bytes = 909.494.702 TB

Consiste in una combinazione di file system e gestore di volumi logici.

ZFS è un progetto open-source nato nel 2004 e sviluppato dalla Sun Microsystems per il suo sistema operativo basato su UNIX che cominciò ad adottarlo nel 2006 dalla versione OpenSolaris 10 build 27.

È stato progettato da un team con a capo Jeff Bonwick ed ora il nome ZFS è registrato come un marchio di Oracle.

CARATTERISTICHE 1/2

File system a 128 bit

La dimensione massima gestibile dei dati è miliardi di volte più grande degli attuali file system a 64 bit, Il limite teorico è infatti di 16 Exabyte

Copy on Write
Nessun blocco del disco contente dati attivi viene mai sovrascritto in operazioni di modifica. I dati modificati vengono scritti in un nuovo blocco assegnato per l’operazione.
Le operazioni Copy-On-Write avvengono in modo tale da spostare il puntatore al blocco di dati dopo il completamento della transazione: in questo modo, i puntatori ai dati “buoni” non si spostano finché la scrittura non è completa, e non c’è bisogno di filesystem journaling, logging, o di un resync del mirror se la macchina si riavvia inaspettatamente.

Snapshot

Invece di cancellare i vecchi dati rimasti, in seguito a operazioni di modifica eseguite con il sistema Copy on Write, ZFS può mantenere le vecchie informazioni insieme a quelle nuove riuscendo così a creare velocemente istantanee del sistema.
Il limite teorico di snapshots e’ di 248 (2 × 1014).

CARATTERISTICHE 2/2

Gestione ottimizzata per file di piccole dimensioni

Con l’aumentare della capacità dei moderni dischi fissi, la registrazione dei file di piccole dimensioni è diventata sempre meno efficiente, stesso discorso per la lettura e la scrittura. ZFS risolve entrambi questi inconvenienti

Gestione logica per sistemi di archiviazione composti da più dischi

I file system tradizionali risiedono su un unico dispositivo, così necessitano di un sistema per la gestione dei volumi quando lavorano con più unità.
ZFS lavora con un sistema virtuale di dischi, rendendo così possibile l’aggiunta di un disco senza dover formattare o partizionare nulla.

End-to-End checksumming

Nei file system tradizionali il checksum è salvato all’interno del blocco stesso che controlla senza una verifica esterna di validità. Le possibilità di errore vengono risolte da questo file system salvando il checksum al di fuori del blocco, e tra questo e il cosiddetto uberblock, che è l’unico ad avere un checksum auto-validante SHA-256. Tutti i controlli sui blocchi vengono effettuati in modo tale che gli errori vengano intercettati senza peraltro mettere in ginocchio la CPU.

Capacità di ZFS

Alcuni dei limiti teorici di Zettabyte File System (ZFS):

  • 248= numero di snapshot;
  • 248= numero di file;
  • 16 exabyte= 16.777.216 TB dimensione massima di un file system;
  • 16 exabyte = 16.777.216 TB dimensione massima di un file singolo;
  • 16 exabyte = 16.777.216 TB dimensione massima di un attributo;
  • 3 × 1023 petabyte dimensione massima di uno zpool;
  • 256 numero di attributi di un file (attualmente limitato a 248);
  • 256 numero di file in una directory (attualmente limitato a 248);
  • 264 numero di device per ogni zpool;
  • 264 numero di zpools;
  • 264 numero di file system in uno zpool.

Un utente che volesse creare mille file al secondo, impiegherebbe 9000 anni a raggiungere il limite

FOCUS DEL PROGETTO ZFS : DATA INTEGRITY – INDRODUZIONE ALLA PROBLEMATICA

Una caratteristica importante che distingue ZFS da altri file system ZFS è che è il principale obiettivo del progetto era rivolto a preservare l’integrità del dato.

In particolare ZFS utilizza un insieme di tecnologie per preservare i dati dell’utente su disco contro la corruzione di dati che notoriamente possono avvenire per un alto numero di cause sia con utilizzo di hard disk che di SSD.

È noto che i sistemi RAID tradizionali fino ad oggi conosciuti sono affetti da diverse problematiche, tra le più importanti possiamo citare:

  • bit error (statisticamente 1 ogni 10^16 transazioni)
  • bit rot (inversione silente di un bit o di un gruppo di bit con il perdurare del tempo di vita del device)
  • picchi di corrente
  • bug nel firmware del disco
  • phantom read/write (la lettura/scrittura di un blocco scritto con dati errati che però possiede un hash coerente calcolato su dati errati)
  • errate letture / scritture (gli accessi al disco indirizzate su blocchi errati)
  • errori di parità DMA tra la memoria dell’array e il server
  • errori del driver (dato che il checksum convalida dati all’interno dell’array)
  • errori del driver (i dati finiscono nel buffer sbagliato all’interno del kernel)
  • sovrascritture accidentali (come ad esempio lo scambio di un file system in real time)

L’integrità dei dati è una priorità in ZFS perché una recente ricerca dimostra che nessuno dei file system attualmente diffusi (come UFS, Ext, XFS, JFS, NTFS) forniscono una protezione sufficiente contro tali problemi .

DATA INTEGRITY 1/3 – COPY ON WRITE 

Nei sistemi RAID convenzionali la scrittura/modifica dati avviene in 3 fasi con con questa sequenza (esempio RAID 5 con 5 dischi)

Situazione iniziale, la parità è stata calcolata con i dati dei dischi 1-2-3-4 e scritta sul disco 5Immagine

  1. Sul disco 1 vendono scritti/modificati i dati
  2. La parità viene ricalcolata sulla base dei nuovi dati
  3. Il nuovo valore della parità viene scritto/modificato sul disco

In un sistema RAID tradizionale qualsiasi tipo di fault impedisca il completamento di tutte e 3 le fasi di transizione il file system diventerebbe inconsistente e provocherebbe danni in seguito soprattutto in fasi delicate come per esempio la rebuild dell’array in caso di sostituzione disco oppure fallimento del processo di verifing in caso di riavvio dopo un’interruzione di corrente.

ZFS non sovrascrive mai i blocchi dati, ogni scrittura viene eseguita su blocchi liberi e solo al termine del processo di convalida del dato vengono spostati i puntatori sui nuovi blocchi dati.

DATA INTEGRITY 2/3 – CHECKSUM 1/2

ZFS utilizza per convalidare l’integrità dei dati un checksum hash basato sull’algoritmo SHA-256 su tutto l’albero del file system.Immagine1

Per ogni blocco di dati viene generato un checksum e il suo valore viene quindi salvato nel puntatore di tale blocco invece che nel blocco vero e proprio. Il puntatore di blocco genera anch’esso un valore di checksum che viene salvato nel blocco del suo rispettivo puntatore.

Questa gerarchia di checksum scala fino al nodo radice (UBER BLOCK) il quale possiede anche lui dati di checksum, creando così un albero Merkle.

In tutti gli altri file system i valori di checksum sono salvati negli stessi blocchi usati per i dati in modo sequenziale, in caso di problemi hardware nella lettura o scrittura consente di eseguire phantom write e phantom read poiché viene generato un checksum coerente con i dati che però sono sbagliati, ma questo errore è silente e non viene evidenziato al file system.

Immagine2

DATA INTEGRITY 2/3 – CHECKSUM 2/2Immagine3

Quando si accede a un blocco, indipendentemente dal fatto che si tratta di dati o meta-dati, il suo checksum viene calcolato e confrontato con il valore di checksum di quello che “dovrebbe” essere. Se i risultati corrispondono, i dati vengono passati allo stack di programmazione per il processo che l’ha richiesto.Se i valori non corrispondono, allora ZFS può riparare i dati accedendo alla ridondanza (mirroring o RAID Z).ZFS potrà recuperare una copia dei dati integra e ricalcolare il checksum risultante, se i dati superano questo controllo di integrità il sistema può quindi aggiornare la copia difettosa e la ridondanza può essere ripristinata.

DATA INTEGRITY 3/3– COERENZA PERSISTENTE

Le fasi di scrittura/modifica DATI in ZFS seguono questo criterio:Immagine4

1.Albero blocchi iniziale convalidato

2.Scrittura/modifica DATI (ZFS usa sempre blocchi liberi per la scrittura/modifica DATI lasciando inalterati i blocchi iniziali).

3.A seguito della modifica DATI vengono calcolati con algoritmo SHA-256 i nuovi metadati di checksum che vengono scritti sui blocchi dei nuovi puntatori dei dati modificati (anche per i metadati modificati ZFS usa sempre blocchi liberi senza sovrascrivere quelli esistenti)

4.Il processo di checksum raggiunge l’UBER BLOCK che viene aggiornato, da questo momento i nuovi dati sono convalidati ed in caso di richiesta verranno forniti quelli nuovi.

Le fasi di scrittura/modifica DATI in ZFS seguono questo criterio:

Albero blocchi iniziale convalidato Scrittura/modifica DATI (ZFS usa sempre blocchi liberi per la scrittura/modifica DATI lasciando inalterati i blocchi iniziali).A seguito della modifica DATI vengono calcolati con algoritmo SHA-256 i nuovi metadati di checksum che vengono scritti sui blocchi dei nuovi puntatori dei dati modificati (anche per i metadati modificati ZFS usa sempre blocchi liberi senza sovrascrivere quelli esistenti)Il processo di checksum raggiunge l’UBER BLOCK che viene aggiornato, da questo momento i nuovi dati sono convalidati ed in caso di richiesta verranno forniti quelli nuovi.

READ WRITE FLOW

READ

1.Tentativo di lettura dal blocco su ARC.

2.Se il blocco non è presente in ARC vine cercato in L2ARC.

3.Se il blocco non è presente in L2ARC viene richiesto dallo Storage POOL.

Immagine5

WRITE

1.Le scritture sincrone sono prima effettuate a livello ARC.

2.Le scritture sincrone sono copiate in ZIL.

3.Al completamento della scrittura del dato in ZIL (storage persistente) viene inviata al client la conferma di scrittura.

4.Infine I dati sono copiati in maniera asincrona da ARC allo Storage POOL, la copia presente sullo ZIL viene cancellata per rendere disponibile lo spazio per le successive transazioni.

GESTIONE ARC E L2ARC

ZFS utilizza un algoritmo proprietario per l’ottimizzazione del popolamento dei due liverlli di cache, I criteri ri riempimento sono legati alla più recente utilizzazione ed alla più frequente richiedsta dei dati.

0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *