Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Sistemi Operativi Analisi e confronto dei meccanismi di journaling adottati nei file system di ultima generazione (ZFS, brtfs, ext4, NTFS) Anno Accademico 2012/2013 Candidato: Jacopo Russo matr. N

2 Ai miei amici, senza di loro non ce l avrei fatta

3 Indice Introduzione 5 Capitolo 1. Journaling File System classici NTFS Struttura ed utilizzo del log Checkpointing Ripristino Riempimento del log Ext Struttura ed utilizzo del journal Checksumming Critiche 14 Capitolo 2. Journaling File System alternativi: COW based Copy-on-write ZFS Struttura Checksum end-to-end Ripristino Silent data corruption RAID-Z Resilvering Riepilogo Btrfs Struttura Checksum Aggiornamento dei dati e ripristino Fsync 26 Capitolo 3. Journaling File System alternativi: flash oriented NILFS UBIFS YAFFS 31 III

4 Capitolo 4. Confronto fra le soluzioni proposte 33 Conclusioni 35 Bibliografia 36 IV

5 Introduzione Quando viene a mancare l alimentazione in un sistema informatico tutte le operazioni che hanno luogo al suo interno vengono bruscamente interrotte, senza che vi sia un esplicito comando di terminazione. In tali circostanze alcune componenti possono continuare a lavorare più a lungo rispetto ad altre, come ad esempio accade per i dispositivi di memorizzazione. Le memorie volatili, non aggiornate propriamente, vedranno un rapido degrado dei dati contenuti in esse. Allo stesso tempo i dispositivi di memorizzazione fissa ed i moduli DMA manifesteranno una durata residua leggermente superiore. Se si dovesse manifestare un calo di tensione contestualmente alla scrittura sul disco, si avrebbe la memorizzazione di una certa quantità di dati corrotti, nonché la perdita di tutte le informazioni parzialmente sovrascritte. La suscettibilità agli arresti improvvisi rappresenta un problema ancora più critico per file system che fanno ricorso a tecniche di codifica. In questo caso, infatti, la variazione indesiderata di un singolo bit implica la perdita dell intera informazione memorizzata. Un primo approccio al problema fu rappresentato negli anni 80 dall implementazione di tool dedicati al recupero della consistenza dei dati, come fsck (File System Check) per i sistemi Unix e dal suo equivalente per i sistemi Windows, chkdsk (CHecK DiSK). Tali tool prevedono la scansione dell intero volume di memorizzazione alla ricerca di file o directory che non possono essere ricollocati automaticamente nella gerarchia di 5

6 indicizzazione del sistema. In una seconda fase, se non avesse successo una riparazione automatica basata sui dati contenuti nel file system, sarebbe demandato all amministratore del sistema il ripristino di tali collegamenti. Un approccio di questo tipo ha tuttavia manifestato nel tempo pesanti limitazioni: La durata della fase di scansione dipende fortemente dalla dimensione del disco (condizione resa insostenibile dalle crescenti dimensioni dei dispositivi di memorizzazione). Scansione e riparazione dei file danneggiati sono eseguibili solo su file system offline, o comunque impostati in sola lettura. Tali restrizioni hanno portato allo sviluppo di nuove politiche di gestione dei dati, capaci di assicurare un certo livello di affidabilità. Saranno in seguito trattati diversi file system relativi a variegati ambienti ed esigenze, ma legati da un filo comune: tutti pongono le basi sul meccanismo del transaction processing. Un sistema transazionale mira a conservare l integrità di un insieme di dati assicurando che l esecuzione di operazioni interdipendenti sia completata integralmente oppure totalmente abortita. Un file system transazionale ha a disposizione gli strumenti adatti per far fronte a guasti improvvisi: l invalidamento di tutte le transazioni completate in modo parziale ha l effetto di riportare il sistema ad uno stato consistente precedente al sopraggiungimento del guasto, come se quest ultimo non si fosse mai verificato. 6

7 Capitolo 1 Journaling File System Classici Un journaling file system presenta fra le sue principali caratteristiche la capacità di tenere traccia dell evoluzione dello stato del sistema, in modo da garantire in ogni momento la consistenza delle informazioni in esso contenute. Ciascuna operazione dedicata alla modifica dei dati contenuti sul disco è accompagnata dalla sua annotazione su un diario (detto journal), costituito da un registro circolare allocato in una particolare area di memorizzazione. Periodicamente le modifiche annotate sul diario vengono riversate sul disco, in modo tale da costituire un punto di ripristino consultabile dal sistema in seguito ad eventi di arresto inaspettato, per riportare lo stesso ad uno stato consistente. Ad una prima analisi sembrerebbe lecito sollevare una maliziosa osservazione: ciò non equivale forse a spostare il problema dell inconsistenza dal file system al journal stesso? Ciò tuttavia non trova riscontro nella realtà, poichè se si verificasse un guasto proprio durante la scrittura del journal verrebbero semplicemente ignorate tutte le transazioni ad esso inerenti, lasciando il sistema in uno stato non aggiornato, ma pur sempre integro. È possibile distinguere diverse categorie di journaling in base alla valutazione di due parametri : come si tiene traccia delle transazioni, e cosa viene annotato nel diario. In base al primo parametro si differenziano : Journaling fisico : il sistema tiene traccia del contenuto dei blocchi fisici coinvolti nell operazione (la descrizione si attesta a livello di memorizzazione). 7

8 Journaling logico : il sistema registra quali modifiche verranno apportate in termini di operazioni logiche. (vengono annotati cambiamenti al livello del file system). Relativamente al secondo parametro sono classificate, in ordine di affidabilità : Modalità writeback : si tiene nota dei soli metadati del file system, ed i blocchi dati vengono scritti nelle loro locazioni, senza che vi sia ordine tra le due operazioni. Coi comporta discreti vantaggi prestazionali, al costo di una garanzia di integrità molto debole (se venissero registrati in memoria prima i metadati e poi i dati, un guasto fra le due operazioni renderebbe questi ultimi irrecuperabili). Modalità ordinata : simile alla precedente, essa impone la scrittura ordinata dei dati, seguita dall aggiornamento del journal. Anche in questo caso l annotazione riguarda solo le modifiche apportate ai metadati. Modalità dati : il journal contiene informazioni sulle modifiche dei metadati e dei dati. Si garantisce la massima protezione contro la corruzione dei dati, al costo di un ingente degrado delle prestazioni (il numero delle operazioni di scrittura viene di fatto raddoppiato). Figura 1: Modalità di journaling. 8

9 L operazione che conferma l avvenuto completamento di una transazione è detta commit, Il commit del journal stesso, ovvero l operazione di trascrizione di quest ultimo sul disco, può essere innescato da diversi fattori come lo scadere di un timeout oppure l esaurimento dello spazio in memoria dedicato al journal. È possibile che, per ragioni di throughput, il sistema operativo attui delle politiche di riordino delle operazioni di scrittura (e.g. algoritmo dell ascensore), a prescindere dalla modalità di journaling adottata. Per di più molti dispositivi di archiviazione sono dotati di cache di scrittura dedicate, gestite attraverso ulteriori politiche di riordinamento. Per ovviare a tale inconveniente alcuni file system sacrificano le proprie performance per assicurare un corretto ordine delle operazioni attraverso l imposizione al dispositivo di memorizzazione di barriere di sincronizzazione. 1.1 NTFS NTFS (New Technology File System) è stato presentato da Microsoft nel 1993 per il sistema operative windows NT 3.1. Nonostante non siano pubblicamente reperibili codice sorgente o documentazione di NTFS, studi di ingegneria inversa hanno delineato la struttura adottata per l implementazione del journaling. Tale file system considera ogni oggetto come file, perfino i metadati. Lo stesso journal è un file (Log file), collocato al centro del file system. L implementazione adottata si basa sul meccanismo del journaling logico, dedicato ai metadati in modalità ordinata, ottenuta mediante l applicazione di un ritardo forzato sulle operazioni di scrittura. La gestione del journal è affidata al Log File Service (LFS), che implementa le routine del kernel necessarie all aggiornamento del journal ed al servizio di ripristino del sistema Struttura ed utilizzo del log Il file di log è suddiviso in due regioni: l area di riavvio (restart area) e l area di annotazione (logging area). LFS viene richiamato dal file system per leggere o scrivere la restart area, nella quale sono contenute le informazioni utili ad un eventuale operazione di ripristino, come ad esempio la locazione della logging area dalla quale cominciare a 9

10 leggere. LFS memorizza anche una seconda copia della restart area, in modo da poter far fronte all ipotizzabile corruzione della prima copia. La logging area è strutturata come una coda circolare (per tale motivo è detta anche infinite logging area), nella quale ogni elemento è contrassegnato da un Log Sequence Number (LSN), e possiede due update record (redo information, undo information). Figura 2:Struttura del log NTFS LFS memorizza nella logging area un record per ciascuna sub-operazione che che compone una transazione. Tale record contiene le informazioni utili a riapplicare tutte le transazioni correttamente concluse (redo information) e riavvolgere quelle parzialmente completate (undo information). Nuovi update record vengono aggiunti all atto di creazione, cancellazione, troncamento, rinominazione o cambiamento degli attributi di un file. Figura 3:Struttura della logging area Checkpointing Per facilitare l operazione di ripristino, evitando di scorrere l intera logging area, NTFS implementa un meccanismo di checkpoint. Ogni otto secondi 1 viene salvato un particolare record di checkpoint nella logging area, ed il suo LSN viene salvato nella restart area. In 1 Charles M. Kozierok, The PC Guide,

11 questo modo LFS, una volta richiamato, potrà usare tale LSN per trasferire dalla memoria centrale al disco un certo numero di record, per poi effettuare un operazione di commit sul journal. Figura 4:Checkpointing NTFS Ripristino In caso di arresto inaspettato del sistema, NTFS provvederà all avvio della procedura di ripristino, scandita dai seguenti passi: NTFS legge la Master File Table (MFT) ed avvia il LFS LFS accede al log e legge dalla restart area l LSN relativo all ultimo checkpoint Viene effettuata una fase di redo. Alla fine di essa, la cache riflette lo stato del dispositivo quando è avvenuto il crash. Viene effettuata una fase di undo. Alla fine di essa il dispositivo è ripristinato ad uno stato consistente Riempimento del log L implementazione della logging area mediante l uso di un buffer circolare può portare ad una situazione di saturazione dello stesso. Questo fenomeno è gestito da NTFS attraverso il lancio di un eccezione volta a bloccare tutte le transazioni in atto, che saranno riprese successivamente, e riavvolgere quelle parzialmente completate. In questo modo il sistema avrà modo di svuotare le proprie cache (journal compreso) sul disco e riprendere le transazioni poste in attesa, sfruttando un log stavolta vuoto. 11

12 1.2 ext4 Ext4, o fourth extended file system, è stato presentato nel 2008 per il sistema operativo Linux. Esso riprende la struttura base del suo predecessore ext3 (già dotato di journaling), introducendo diverse caratteristiche aggiuntive, tra le quali il meccanismo del checksumming, volto a rafforzare l integrità dei dati. Così come ext3, ext4 supporta tutte le modalità di journaling (data, writeback, ordered), applicata ai blocchi (journaling fisico). Come già accennato, ciò comporta un maggiore grado di affidabilità, al prezzo di un maggior overhead poichè la struttura di ext4 è basata su inode, la cui dimensione è inferiore al blocco, la variazione di un singolo bit in un singolo inode si traduce nella copia sul journal dell intero blocco, contenente anche gli inode vicini, non implicati nell operazione Struttura ed utilizzo del journal Identicamente ad NTFS, il journal ext4 è un file, residente all interno del file system (comunemente) è prevista la possibilità di memorizzare il journal anche su un diverso supporto. Il journal è strutturato in blocchi di diversa tipologia: Superblock, che mantiene informazioni sul journal stesso, come la dimensione dei blocchi di cui è composto; il numero totale di blocchi a disposizione; la locazione dove effettivamente inizia il journal; il numero di sequenza della prima transazione e la sua locazione in memoria. Descriptor block, ogni transazione contiene una descrizione delle locazioni finali dei blocchi dati che seguono nel journal. Metadata block, uno o più per ogni transazione. È qui che vengono registrate le modifiche apportate al sistema. Nel caso in cui si adotti il data journaling, tali blocchi rispecchiano anche i dati coinvolti nella scrittura. Commit block, indica la terminazione di una transazione effettuata con successo. 12

13 Revoke block, contenente la lista dei blocchi che non dovrebbero essere riscritti nel file system, per esempio nel caso in cui vi sia una dipendenza ciclica tra due transazioni,ed una di esse non sia stata ancora confermata nel journal. In ogni caso tali blocchi possono essere scritti sul disco nel caso in cui il sequence number sia più alto rispetto a quello del revoke block. Figura 5: struttura del journal ext4 Tutti i blocchi descritti, fatta eccezione per i metadata, sono detti blocchi amministrativi e condividono nei primi 12 byte un header di identica struttura. Il sistema tratta tutte le operazioni in esecuzione come un unica transazione globale. Nonostante ciò si rifletta in un miglioramento delle prestazioni, è possibile che dia luogo a raggruppamenti di operazioni incorrelate, che possono portare ad un intreccio tra traffico sincrono ed asincrono nel file system. Le politiche di commit e di checkpiont delle transazioni variano in base a tre fattori: richiesta di sincronizzazione da parte di un applicazione; dimensione del diario; impostazione del timer di commit Checksumming Il meccanismo di checksum aggiunto in ext4 permette di rilevare più facilmente fenomeni di corruzione dei dati riguardanti il journal stesso, reso vulnerabile dalle continue operazioni di scrittura ad esso applicate. Inoltre rende più efficienti le meccaniche di annotazione del sistema, introducendo sostanziali miglioramenti delle performance. Durante le normali operazioni di journal, il blocco di commit viene scritto solo quando tutte le informazioni su header e metadati sono state registrate (commit a due fasi); e la transazione successiva dovrà attendere tale commit per poter procedere. Una transazione è giudicata ripetibile solo se header e commit block hanno lo stesso transaction number. 13

14 La situazione cambia con l adozione del checksumming: viene generato un CRC32 sul gruppo di blocchi che compone la transazione, che sarà registrato all interno del blocco di commit. Se in fase di ripristino dovesse fallire il controllo su tale checksum, l intera transazione verrebbe scartata. In questo modo viene meno l esigenza di un commit a due fasi per ogni transazione: il blocco di commit può essere scritto contemporaneamente agli altri, comportando un sensibile miglioramento delle prestazioni del file system (intorno al 20% 2 ), contrariamente a quanto potrebbe far intuire l introduzione di un campo aggiuntivo Critiche Per migliorare le prestazioni in fase di scrittura ext4 utilizza la tecnica dell allocazione ritardata (allocate-on-flush): l allocazione dei blocchi avviene in due fasi (prenotazione ed allocazione), in modo tale da mantenere i dati quanto più possibile nella cache. Molti file infatti hanno vita breve, ed in questo modo è possibile farne uso senza doverli allocare sul disco. Anche i file più longevi traggono vantaggio da questa tecnica poiché il kernel ha a disposizione più dati da poter allocare in maniera contigua, riducendo sensibilmente la frammentazione e velocizzando di conseguenza le operazioni di lettura e scrittura. L allocazione ritardata presenta tuttavia dei forti effetti collaterali: il mantenimento prolungato dei dati all interno della cache non fa altro che vanificare gli sforzi compiuti dal meccanismo di journaling per preservarne la consistenza: a favore delle performance si va a contrastare il processo di allocazione ordinata, permettendo che la scrittura dei metadati anticipi quella dei dati ad essi afferenti. Linus Torvalds, coordinatore del progetto di sviluppo Linux, ha espresso tutto il suo turbamento riguardo l introduzione dell allocazione ritardata nella mailing list degli sviluppatori Linux: 2 Vijayan Prabhakaran, Lakshmi N. Bairavasundaram, Nitin Agrawal, Haryadi S. Gunawi, Andrea C. Arpaci-Dusseau, and Remzi H. Arpaci Dusseau. Iron file systems,

15 "Doesn't at least ext4 default to the insane model of 'data is less important than metadata, and it doesn't get journalled'? And ext3 with 'data=writeback' does the same, no? Both of which are -- as far as I can tell -- total brain damage. At least with ext3 it's not the default mode.[ ] if you write your metadata earlier (say, every 5 sec) and the real data later (say, every 30 sec), you're actually more likely to see corrupt files than if you try to write them together... This is why I absolutely detest the idiotic ext3 writeback behavior. It literally does everything the wrong way around -- writing data later than the metadata that points to it. Whoever came up with that solution was a moron. No ifs, buts, or maybes about it." 3 ext4 non aderisce come minimo al folle modello de i dati sono meno importanti dei metadati, e non c è bisogno di annotarli? Ed ext3 con data=writeback non fa lo stesso? Entrambi sono -- per quanto ne sappia una totale offesa all intelligenza. Almeno in ext3 non è la modalità predefinita.[ ] scrivendo i metadati prima (ad esempio, ogni 5 sec) e i veri dati dopo (ad esempio, ogni 30 sec), sarai più propenso a vedere dati corrotti piuttosto che se provi a scriverli insieme È per questo che io detesto assolutamente il comportamento idiota del writeback di ext3. Fa letteralmente le cose al contrario scrivendo i dati dopo dei metadati che puntano ad essi. Chiunque sia giunto a questa conclusione era un imbecille. Senza se, ma, o forse al riguardo. 3 Britta Wuelfing. Linus Torvalds Upset over Ext3 and Ext4,

16 Capitolo 2 Journaling File System Alternativi: COW based Oltre ai classici meccanismi di journaling, è possibile identificare diverse soluzioni volte a garantire l integrità dei dati costituenti un file system. A differenza di quanto visto finora riguardo tecniche esplicite per il trattamento delle informazioni di gestione, alcuni file system di recente implementazione realizzano un approccio basato sui meccanismi fondamentali di memorizzazione. Tratteremo in questo capitolo due dei maggiori esponenti della filosofia copy-on-write attualmente sul mercato: ZFS e btrfs. 2.1 Copy-on-write Il principio del copy-on-write (spesso abbreviato COW) pone le sue basi nell ambito della programmazione concorrente: consentire a diversi processi l accesso alla medesima risorsa, fornendo a ciascuno un riferimento ad essa. Una eventuale modifica della risorsa condivisa non sarà tradotta nella sovrascrittura del dato originale, bensì darà luogo ad una nuova versione di esso, memorizzata in una locazione diversa dalla precedente. Figura 6: modifica copy-on-write di un nodo in una struttura ad albero (es. nodo 34) 16

17 Una implementazione possibile del copy-on-write si può ottenere comunicando alla MMU che determinate pagine nello spazio di indirizzamento sono a sola lettura. Un operazione di scrittura su di esse solleverà un eccezione gestita dal kernel, che allocherà nuovo spazio in memoria dove saranno depositate le nuove copie. Applicato al contesto d analisi, tale meccanismo consente al file system di tenere traccia delle modifiche apportate ad esso (mediante snapshots, ovvero istantanee dello stato del sistema precedenti a determinate operazioni). È possibile riportare il sistema ad uno stato consistente a fronte di un guasto improvviso semplicemente spostando i riferimenti di un file danneggiato all ultima versione sana contenuta in memoria. Sotto queste ipotesi viene meno la necessità di annotare esplicitamente le modifiche apportate al sistema: il file system implementa la strategia di ripristino nella struttura stessa che lo compone. 2.2 ZFS ZFS (Zettabyte File System) è un file system open source sviluppato dalla Sun Microsystems per il suo sistema operativo Solaris, rilasciato nel novembre I princìpi alla base di tale file system traggono la loro ispirazione da diversi prodotti già sul mercato, come l uso di snapshots di Network Appliance, la gestione object-oriented della memoria e l utilizzo di transazioni e checksum di Veritas. La struttura di ZFS è data dalla combinazione di un file system ed un volume manager. Le istruzioni del file system non necessitano della conoscenza dei dettagli dell effettivo livello fisico sottostante, poichè quest ultimo viene virtualizzato. Le interazioni di alto livello sono gestite da una Data Management Unit (DMU) - un concetto molto simile all MMU, applicato ai dischi. Tutte le transazioni effettuate attraverso la DMU sono considerate atomiche, a garanzia della consistenza dei dati. 17

18 Figura 7: Virtualizzazione della memoria in ZFS Struttura La struttura adottata da ZFS per la memorizzazione delle informazioni è costituita da un albero di blocchi, ed il meccanismo delle transazioni è associato a quello del copy on write, per cui nuove informazioni sono scritte su blocchi diversi, ed il puntatore al dato in uso è aggiornato solo all atto di conferma della transazione. Tale evento si ripete sull intera gerarchia del file system, fino al nodo principale, detto uberblock. Figura 8: Aggiornamento di un blocco in ZFS 18

19 2.2.2 Checksum end-to-end Molti file system che implementano il meccanismo di checksum garantiscono un integrità dei dati solo parziale, poichè memorizzano tale valore all interno del blocco che contiene l informazione stessa da proteggere. Ciò non permette di far fronte a problemi come: Operazioni di scrittura fantasma, nelle quali i dati (e quindi le checksum) non vengono effettivamente scritti. Operazioni di lettura/scrittura indirizzate in maniera errata. Errori di parità generati durante un trasferimento dati da/verso il DMA. Errori dei driver, per i quali i dati vengono depositati in buffer errati. In ZFS tutti i puntatori ai blocchi contengono un campo checksum di 256 bit, relativo al blocco puntato. La gerarchia di checksum forma un albero di Merkle auto-validante; solamente l uberblock contiene una checksum relativa a se stesso. In un implementazione che sfrutta RAID-Z, di cui discuteremo in seguito, tale meccanismo permette la rigenerazione automatica dei dati. I puntatori ai blocchi utilizzati contengono fino a tre indirizzi, detti DVA (Data Virtual Addresses), riferiti a blocchi differenti che contengono gli stessi dati, detti ditto blocks. La politica standard di ZFS prevede l uso di un DVA per i dati, due per i metadati del file system, e tre per i metadati globali, comuni a tutte le istanze del file system. Indipendentemente dal numero di DVA, ogni puntatore ad un blocco contiene una singola copia della checksum. Figura 9: Struttura di un puntatore a blocco 19

20 2.2.3 Ripristino Il meccanismo di aggiornamento dal basso verso l alto della struttura ad albero, associata all implementazione di una politica di checksum separate dai dati stessi rende il meccanismo di ripristino semplice ed al cotempo efficace: in fase di montaggio del file system viene ripercorso l intero albero a partire dall uberblock. Il controllo della checksum precede ogni passaggio ad un blocco successivo. Nel caso in cui tale controllo dovesse fallire, l albero verrebbe potato del ramo non valido, sostituito da un ditto block, oppure da una versione più vecchia del blocco stesso. Tutti i blocchi in ZFS sono infatti marcati con un parametro temporale, detto birth time, che identifica il gruppo di transazione al quale appartiene il blocco. Figura 10: blocchi ZFS identificati attraverso il birth time Silent data corruption Oltre a garantire l integrità dei dati in caso di guasto, ZFS propone soluzioni per la gestione della corruzione silente dei dati. Studi statistici condotti da alcune case produttrici di sistemi di memorizzazione e dal CERN hanno infatti dimostrato che si verifica un errore non rilevabile dai dispositivi ogni bit 4 a causa di difetti associati a dischi, controllori, cavi, driver o firmware. Ciò rappresenta un problema rilevante per sistemi come i database server che gestiscono 4 Bernd Panzer-Steindel. "Draft 1.3". Data integrity. CERN. 20

21 ingenti moli di dati: il creatore di ZFS, Jeff Bonwick ha affermato che il database della Greenplum importante database software company americana affronta la corruzione silente ogni 15 minuti RAID-Z Per assicurare l integrità dei dati soggetti a corruzione silente, ZFS implementa una funzionalità nota come RAID-Z. Tale soluzione è simile a quella offerta da RAID-5, ma a differenza di esso fa uso di strisce a dimensione variabile, in modo tale da risolvere il problema del write hole : in RAID-5 le operazioni di scrittura sono effettuate su più dischi indipendenti, in maniera non atomica. Un interruzione di servizio tra la scrittura dei dati e del blocco di parità ha come risultato la memorizzazione di dati corrotti. Figura 11: strisce RAID-Z a dimensione variabile Al contrario, la scrittura di una striscia RAID-Z è atomica, ed essendo basata sul copy-onwrite, non necessita di un ciclo read-modify-write. La complessità di RAID-Z si riflette tuttavia nel processo di ricostruzione dei dati: poiché le strisce non sono di dimensione fissa, non è possibile determinarne immediatamente la geometria, bensì è necessario ripercorrere tutti i metadati del file system (ciò può risultare oneroso rispetto al RAID classico) Resilvering In uno scenario RAID tradizionale, la ricostruzione di un dispositivo danneggiato si effettua mediante una elaborazione integrale del disco (mediante un operazione di XOR), 5 "A Conversation with Jeff Bonwick and Bill Moore". Association for Computing Machinery. November 15,

22 anche se quest ultimo è quasi vuoto, e senza che vi sia cognizione di cosa si stia riparando. Il resilvering RAID-Z, al contrario, prevede che sia percorso l albero di sistema a partire dall uberblock, in modo da dare priorità ai blocchi più importanti, ed evitare di lavorare su quelli non in uso, ottenendo un notevole risparmio di tempo. Per il recupero di una transazione può essere utilizzato il dirt time logging (DTL): il sistema tiene traccia del tempo di inattività del disco danneggiato, e nella fase di ripristino provvede alla riapplicazione delle transazioni avvenute in questa finestra temporale, se registrate sugli altri dischi del pool RAID Riepilogo Per ragioni di chiarezza, procediamo ad un riepilogo delle potenzialità di protezione offerte da ZFS: Qualunque sia la configurazione dei dischi, gli errori che si presentano sia sui blocchi dati che sui blocchi metadati sono sempre rilevati, grazie alle checksum. Una configurazione basata su un singolo disco o su più dischi che adottano tecniche di memorizzazione a strisce permette il ripristino dei blocchi metadati, mentre per i dati è necessario l utilizzo dei ditto blocks. Una configurazione basata su più dischi ridondanti (RAID-Z) permette il ripristino del contenuto di qualunque tipo di blocco. 22

23 2.3 btrfs Btrfs (B-tree file system, o Butter FS ) è un file system annunciato da Oracle Corporation nel 2007 (non ancora rilasciato in versione stabile) per il sistema operativo Linux. Esso si distingue dai suoi omologhi (soprattutto ZFS) per il pregio di conciliare la struttura B-tree (Particolarmente performante, in termini di tempi di ricerca, scrittura e cancellazione) con il meccanismo del copy-on-write. Ogni informazione, che si tratti di inode, file dati, cartelle, bitmap è generalizzata come oggetto. In questo modo tutte le operazioni di lettura/scrittura all interno della struttura ad albero sulla quale si regge btrfs condividono lo stesso codice, indipendentemente dalla tipologia di file coinvolta Struttura Tale file system è strutturato come una foresta di composizioni ad albero. Il blocco principale, detto superblock, posizionato in una locazione di memoria fissa, funge da punto d innesto. Esso punta ad un albero delle radici, che indicizza gli alberi che costituiscono il file system vero e proprio. Figura 12: struttura a foresta di btrfs 23

24 All interno di ogni albero è possibile distinguere due sottostrutture : una superiore, costituita dai nodi ramo, ed una inferiore, data dai nodi foglia. Tutti i nodi appartenenti alla sezione superiore sono costituiti esclusivamente da una coppia (chiave, puntatore), dove il primo elemento è utilizzato per indicare la direzione da intraprendere per continuare a percorrere l albero, ed il secondo rappresenta l effettivo indirizzo in memoria del blocco successivo. I nodi della struttura inferiore contengono gli oggetti (citati precedentemente), dati dalla combinazione di header, usati per specificare il tipo di oggetto memorizzato, e dei dati associati ad ogni oggetto. Header e dati sono depositati rispettivamente all inizio ed alla fine del blocco, in modo tale che crescano l uno verso l altro. Figura 13: blocco dati btrfs Un architettura di questo tipo porta con se, rispetto alle strutture tradizionali, un risparmio di spazio (in un unico blocco è possibile memorizzare diversi tipi di informazioni) e di tempo (l accesso ad una particolare sezione di un file non richiede l accesso a diversi tipi di metadati, posizionati in diverse locazioni del file system). 24

25 Figura 13-15: confronto fra allocazione tradizionale e btrfs Checksum Nella struttura principale di btrfs è contemplata la presenza di un albero dedicato esclusivamente alle checksum. Ogni oggetto di questo tipo è riferito ad un particolare extent (che in btrfs equivale a 4kb) e contiene una lista di checksum associate ai vari blocchi.in questo modo viene implementata, al pari di ZFS la separazione fra i dati e le checksum relative ad essi Aggiornamento dei dati e ripristino La modifica di file o directory da luogo una scrittura copy-on-write di nodi foglia, che innesca un aggiornamento a catena di tutti i rami sovrastanti fino al nodo radice. Ogni albero contenente informazioni sul file modificato sarà coinvolto in questo processo. Tali modifiche vengono accumulate in memoria ed in seguito ad un timeout (di default 30 sec), o al raggiungimento di una certa soglia quantitativa sono scritte in batch nelle nuove locazioni del disco, creando un checkpoint. A questo punto viene modificato il superblock in modo tale che faccia riferimento al nuovo checkpoint. Questa è l unica situazione in cui un blocco del disco viene sovrascritto. Per questo motivo l integrità dell intero sistema è garantita dalla presenza di più copie del superblock, posizionate in varie regioni del disco (64KiB, 64MiB, 256GiB, 25

26 1PiB). In fase di aggiornamento, viene incrementato un campo generation number, in modo tale che in fase di montaggio venga scelto il blocco che possiede il valore più alto. Figura 16: aggiornamento di un file in btrfs Tutte le copie del superblock vengono aggiornate in tandem. Se dovesse verificarsi un arresto improvviso del sistema, il file system ripristinerebbe lo stato leggendo il superblock più recente, e seguirebbe i riferimenti fino all ultimo checkpoint valido sul disco. Ciascun nodo registra infatti il generation number in uso al momento della propria creazione, in modo da poter essere associato ad un dato checkpoint. Inoltre ad ogni puntatore al successivo nodo è affiancato il valore del generation number atteso, in modo da rilevare scritture fantasma o maldirette sul disco. In sintesi, la verifica del contenuto di un blocco è possibile grazie all utilizzo congiunto di generation number e checksum Fsync Per sopperire all elevata latenza caratteristica del checkpointing, btrfs offre una funzionalità aggiuntiva volta a garantire una sincronizzazione orientata ad un singolo file, detta fsync. Le modifiche al file system comportate dalla modifica del file sono annotate in uno speciale albero di log. Al verificarsi di un anomalia, l albero di log viene letto come parte della sequenza di ripristino. 26

27 Capitolo 3 Journaling File System Alternativi: Flash oriented Lo sviluppo di nuove tecnologie nel campo dei supporti di memorizzazione sta compiendo grandi passi avanti. L idea comune è che l utilizzo dei classici dischi rigidi rappresenti uno stop-gap in termini di tempi di elaborazione, a causa delle latenze determinate dai processi di seek associati alla natura meccanica del supporto. Un alternativa concreta è rappresentata dalle memorie flash, basate su MOSFET e largamente utilizzate nel settore dei dispositivi portatili, come palmari, lettori MP3, smartphone, fotocamere digitali. Esistono principalmente due tipologie di memorie flash, dette NOR e NAND, che differiscono per l architettura ed il procedimento di programmazione. A dispetto di alte velocità in lettura e scrittura, tuttavia tali supporti presentano dei limiti comuni (che necessitano di particolari strategie di gestione): la scrittura di un blocco richiede necessariamente la previa cancellazione dello stesso. Per di più tale operazione richiede un tempo superiore a quello di una semplice scrittura di almeno un ordine di grandezza, e può essere eseguita un numero limitato di volte (tipicamente ) prima che la cella diventi inutilizzabile. In un simile scenario molte delle politiche adottate dai tradizionali file system divengono inadatte, se non addirittura dannose. Allo stesso tempo nasce la necessità di implementarne di nuove, delle quali due sono fondamentali: 27

28 Garbage collection: dati obsoleti necessitano di essere cancellati per rendere disponibile nuovo spazio in memoria (essenziale per tecniche di memorizzazione out of place ). Contemporaneamente i blocchi soggetti a frequenti operazioni di lettura tendono a dissipare i dati contenuti. L algoritmo di garbage collection mira a spostare il contenuto valido dei blocchi in nuove locazioni, eliminando i dati non più necessari. Wear Leveling: per contrastare lo sviluppo del deterioramento delle celle sottoposte a cicli di lettura-cancellazione-scrittura si punta ad un utilizzo equamente distribuito della memoria, in modo da rallentare il processo di invecchiamento del supporto Tratteremo brevemente tre file system di ultima generazione, progettati per essere tolleranti alle interruzioni improvvise dell alimentazione, in un ambiente basato su memorie flash: NILFS, UBIFS, YAFFS. 3.1 NILFS NILFS (New Implementation of a Log-structured File System) è un file system sviluppato dalla Nippon Telegraph and Telephone Corporation (NTT) per il sistema operativo Linux, rilasciato nel L architettura di NILFS è realizzata dalla sovrapposizione di più strutture: l archivio fisico vero e proprio, un b-tree dedicato all allocazione dei dati, un altro b-tree per gli inode. Per ragioni di compattezza e di attinenza al soggetto di studio non saranno esposte tali strutture nel dettaglio, per maggiori approfondimenti è consigliata la lettura di The NILFS version 1: overview a cura del team di sviluppo NILFS. Per garantire un elevato livello di affidabilità viene adottata al livello fisico una struttura a log (tipica di flash file systems storici, come JFFS): la memorizzazione dei blocchi, indipendentemente dal contenuto, avviene in maniera contigua, ed il dispositivo flash è visto come un log circolare. In tal modo i file non sono aggiornati per sovrascrittura, permettendone la co-esistenza di diverse versioni. 28

29 Figura 17: Log-structured file system Il layout del disco comprende: Superblock: contiene i parametri del file system, l indirizzo sul disco dell ultimo blocco scritto, la radice del b-tree adottato logicamente dal sistema. Data la sua importanza, il superblock è replicato su un altro blocco del disco. Full segment: gruppo di blocchi del disco, di lunghezza fissata. Costituisce l unità base del garbage collector. Partial segment: unità di scrittura del sistema. Logical segment: sequenza inseparabile di partial segments, rappresenta una transazione Figura 1148: Layout NILFS 29

30 Ogni partial segment consiste di tre sezioni: Segment summary: contiene informazioni utili sull utilizzo del blocco, tra le quali una checksum dell area dati. Area dati. Checkpoint: posto in coda al segmento, contiene una checksum del checkpoint stesso, ed un block number relativo alla radice dell inode b-tree. Tale informazione viene scritta per ultima, ed aggiorna lo stato dell intero file system. Riassumendo, le seguenti funzioni garantiscono l affidabilità del file system: Checksum: non esistono checksum per i blocchi individuali, bensì il tool newfs genera casualmente ad ogni transazione un numero a 32 bit e lo deposita nel superblock. Tale numero è utilizzato come valore iniziale dall algoritmo CRC32 per generare le checksum. Il processo di ripristino controllerà la validità delle checksum confrontandole al valore contenuto nel superblock Scrittura ordinata: Tutti i blocchi vengono scritti secondo il seguente ordine: I blocchi dati sono memorizzati sul disco, seguiti dai nodi del b-tree dei dati, dai blocchi inode, ed infine i nodi del btree relativo agli inode. Sovrascrittura minimizzata: Gli unici blocchi ad essere sovrascritti sono il superblock, le sezioni di uso dei segmenti (non trattate in questo discorso), e le loro repliche. 3.2 UBIFS UBIFS (Unsorted Block Image File System) è un file system sviluppato da NOKIA, in collaborazione con l università di Szeged (Ungheria) e rilasciato nel 2008 per il sistema operativo Linux. Tale file system lavora al di sopra di uno strato detto UBI (Unsorted Block Image), che si occupa di gestire il wear leveling attraverso propri meccanismi di amministrazione della memoria fisica, e offre al livello superiore dei blocchi di memorizzazione logica, detti 30

31 LEB (Logical EraseBlocks), propriamente mappati su quelli fisici. UBIFS adotta una struttura B+tree (al pari di btrfs), e memorizza la posizione del nodo radice in un master node, che tiene traccia di tutte le strutture che non sono allocate in posizioni logiche fisse. Per facilitare le strategie di recupero dai guasti, vengono memorizzate due copie del master node. All atto di creazione del file system vengono distinte sei partizioni fisse. Una di queste è detta area di log (o più semplicemente log). Esso è una parte del journal di UBIFS, usato per ridurre la frequenza di aggiornamento dei rami del b-tree. I nuovi nodi foglia sono memorizzati nel journal e, periodicamente, quando quast ultimo è considerato ragionevolmente pieno, è attuata un operazione di commit, che consiste nello scrivere le effettive nuove versioni degli indici e del corrispondente master node. Diversamente da quanto visto in precedenza, l operazione di commit non sposta i nodi foglia dal journal, ma sposta il journal stesso: le informazioni contenute in esso in seguito al commit entrano a far parte del b-tree principale, mentre il journal verrà scritto in una nuova area di memoria libera. Ogni volta che UBIFS viene montato, gli indici del b-tree vengono considerati da aggiornare, in modo da rinnovare le informazioni memorizzate con quelle contenute nel journal. Tale processo è detto replay. L area di log è utilizzata per tenere traccia, in un buffer circolare, della posizione del journal in memoria attraverso un commit start node, che registra l inizio di un commit, e reference nodes, che registrano il numero di LEB che fanno parte del journal, detti Buds. Un commit viene considerato concluso nel momento in cui viene aggiornato il master node, che punterà alla nuova coda dell area di log. Nel caso in cui il commit non dovesse giungere a compimento a causa di guasti improvvisi, il processo di replay ri-applicherebbe sia la sezione di journal già elaborata, sia quella non ancora raggiunta. 3.3 YAFFS YAFFS (Yet Another Flash File System) è un file system sviluppato nel 2002 dalla Aleph One e concepito per diversi sistemi operativi, tra i quali Linux e Android. 31

32 Esso si fonda su una architettura a log, che viene, ad ogni boot, riassemblata in memoria centrale in una struttura ad albero. L unità di memorizzazione adottata è il chunk, che consiste di un header e dei dati, più una spare area che contiene, oltre a vari parametri, un sequence number. Figura 159: montaggio YAFFS Quando si apporta una modifica alla sezione dati viene allocato un nuovo chunk, che conterrà un sequence number incrementato, per intendere che si tratta di una versione successiva del dato. Solo a questo punto il sistema potrà, se necessario, deallocare la vecchia copia. I chunk obsoleti vengono distinti attraverso un valore dirty settato alto all interno della spare area. Quando tutti i chunk in un eraseblock sono marcati come tali, il blocco può essere cancellato e riutilizzato. Il processo di ripristino del sistema è ottenuto ripercorrendo a ritroso il log (quindi in ordine cronologico inverso), in modo tale che tutte le ulteriori coppie (objectid, sequence number) rilevate saranno scartate immediatamente come obsolete. Per velocizzare le operazioni di montaggio del file system è possibile sfruttare un meccanismo di checkpoint: un flusso dati viene scritto in un set di blocchi, marcati come detentori di checkpoint data. Tale flusso conterrà lo stato a runtime del sistema, costituito dalle sole informazioni utili ad avviare il processo di recupero dei metadati, tra le quali un indice di versione, usato per distinguere l ultimo checkpoint da quelli obsoleti; ed un checksum per verificarne l integrità. 32

33 33

34 Capitolo 4 Confronto fra le soluzioni proposte Giunti a questo punto sorge spontaneo chiedersi quale delle soluzioni analizzate sia la migliore. È immediato comprendere tuttavia che è difficile, se non impossibile, poter sostenere un confronto assoluto a causa della mole di parametri in gioco. Le meccaniche di journaling classico potrebbero dimostrarsi poco adatte a soddisfare le attuali richieste in materia di affidabilità, considerando un ambiente che contempla il trattamento di ingenti quantità di dati e che vede affacciarsi all orizzonte problematiche che in un passato non lontano erano considerabili di poco conto. D altro canto l esperienza accumulata da tali file system li rende dei veterani nel settore, ai quali è possibile attribuire un certo grado di stabilità. I file system COW based hanno dalla loro la forza di un meccanismo dedicato a preservare le vecchie informazioni nonostante l evolversi dello stato del sistema, che, se ben sviluppato, può risultare praticamente infallibile. L altra faccia della medaglia si manifesta di conseguenza: la qualità ha un costo, che in termini di risorse si rivela abbastanza alto, a causa della richiesta da soddisfare per poter gestire le meccaniche di conservazione e ridondanza dei dati. Non bisogna inoltre ignorare la relativa immaturità dei file system COW based: al giorno d oggi sono ancora in atto studi volti a risolverne bug ed inesattezze (basti pensare che per btrfs non è ancora stata rilasciata una versione stabile). 34

35 L assenza dei file system dedicati alle memorie flash da questo confronto non è casuale. La relatività alla quale si faceva riferimento ad inizio discorso viene in questo caso amplificata di ordini di grandezza. Le memorie flash hanno già conosciuto una notevole fama nel mondo dei sistemi embedded, ma non sono ancora considerabili definitivamente mature da poter costituire una valida alternativa ai supporti di memorizzazione classici. La ricerca in questa direzione sta incontrando purtroppo non pochi ostacoli, a causa della reticenza mostrata dalle case produttrici di memorie flash, disposte per il momento alla sola offerta di soluzioni proprietarie per la gestione della memoria al livello fisico (Le memorie SSD, attualmente in commercio, dispongono di un controllore autonomo, unico beneficiario dell accesso al livello fisico, ed intermediario fra esso ed il file system). Nel campo dei dispositivi mobili le memorie flash rappresentano uno standard de facto, ed è proprio grazie all applicazione in questo campo - che di recente sta avendo molto successo grazie all ampia diffusione degli smartphone - che i file system dedicati a tale supporto conosceranno presto un notevole sviluppo. 35

36 Conclusioni L analisi condotta conduce alla seguente conclusione: esiste una variegata gamma di possibilità quando si parla di file system failure-aware. Allo stesso tempo, tuttavia, la risposta ad un possibile confronto si traduce in un ingegneristico dipende. È possibile classificare tali file system in termini di affidabilità, prestazioni, requisiti senza ottenere due volte la stessa scala di importanza. La soluzione che si potrebbe prospettare al momento più saggia consisterebbe nell affidare il mercato general purpose, meno delicato in termini di valore dei dati e meno esigente in termini di prestazioni, ai meccanismi di journaling classico, per ora più stabili. Il mondo delle grandi aziende e dei data server si prospetta invece come un ottimo banco di sperimentazione, in vista di uno sviluppo definitivo delle più moderne tecniche di gestione di grandi quantità di dati. 36

37 Bibliografia [1] Valerie Aurora. 2009, A short history of btrfs [2] Jeff Bonwick, Bill Moore. ZFS The Last Word In File Systems [3] Wiebe Cazemier. Why power outages are bad for your data [4] Dominique Heger. An Introduction to ZFS The Next Generation in File System Technology [5] Adrian Hunter. 2008, A Brief Introduction to the Design of UBIFS [6] M. Tim Jones. 2008, Anatomy of Linux flash file systems [7] M. Tim Jones. 2008, Anatomy of Linux journaling file systems [8] Jeffrey B. Layton. 2009, NILFS: A File System to Make SSDs Scream [9] Charles Manning. 2010, How YAFFS Works [10] Joe Peterson. 2008, More on data integrity: Enter Btrfs! [11] Vijayan Prabhakaran. 2006, IRON FILE SYSTEMS [12] Ohad Rodeh. 2012, BTRFS: The Linux B-tree Filesystem [13] Britta Wuelfing. 2009, Linus Torvalds Upset over Ext3 and Ext4 [14] Avantika Mathur, Mingming Cao, Suparna Bhattacharya, Andreas Dilger, Alex Tomas, Laurent Vivier. 2007, The new ext4 filesystem: current status and future plans [15] Vijayan Prabhakaran, Lakshmi N. Bairavasundaram, Nitin Agrawal, Haryadi S. Gunawi, Andrea C. ArpaciDusseau, and Remzi H. ArpaciDusseau. 2005, Linus Torvalds Upset over Ext3 and Ext4IRON File Systems, pagg [16] Yupu Zhang, Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci- Dusseau. End-to-end Data Integrity for File Systems: A ZFS Case Study [17] Yuanting Wei, Dongkun Shin. NAND Flash Storage Device Performance in Linux 37

38 File System [18] NTFS Developers. NTFS.COM/Transaction Journal [19] Btrfs wiki moderators wiki.kernel.org/btrfs 38