Analisi dei file system con journaling

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Sistemi Operativi Analisi dei file system con journaling Anno Accademico 2012/2013 Candidato: Antonio Perna matr. N

2

3 Indice Introduzione 4 Capitolo 1. File System con Journaling: Concetti Generali Modelli di Journaling Data Journaling Ordered Journaling Writeback Journaling Confronto tra le modalità di Journaling Log-Structured File System Gestione dei file La Garbage Collection Ripristino e log file 17 Capitolo 2. File System con Journaling nei sistemi operativi Linux e Windows Ext Struttura dati Funzionalità aggiuntive di Ext Ext Il Journaling in Ext Journaling Block Device Ext Struttura ed utilizzo del journal Checksumming Altre caratteristiche NTFS Log File Service Checkpointing Ripristino Confronto tra i file system analizzati 36 Conclusioni 38 Bibliografia 40 III

4 Introduzione Il file system gestisce un insieme di strutture dati per implementare le astrazioni previste: file, directory e tutti gli altri metadati necessari per sostenere le astrazioni di base che ci si aspettano da un file system. A differenza di molte strutture dati (ad esempio quelle che si trovano in memoria di un programma in esecuzione), quelle del file system devono persistere, cioè, devono sopravvivere per un lungo periodo, infatti questi vengono memorizzati su dispositivi che conservano i dati nonostante la mancanza di alimentazione ( come hard disk o SSD ). Una delle sfide principali di un file system è quella di aggiornare strutture dati persistenti, nonostante l improvvisa mancanza di alimentazione o un errore di sistema. In particolare, cosa succede se, nel mezzo di un aggiornamento di una struttura dati, qualcuno inciampa nel cavo di alimentazione e il computer si spegne improvvisamente? O il sistema operativo incontra un bug e crash? Queste situazioni comportano un nuovo problema nell implementazione del file system, noto come crash-consistency problem. Tale problema è abbastanza semplice, infatti, ipotizziamo che bisogna aggiornare due strutture dati sul disco, A e B, al fine di completare una particolare operazione. Poiché viene processata una singola richiesta alla volta, solo una di queste due raggiungerà il disco per prima. Se si dovesse manifestare una mancanza di alimentazione o un errore di sistema dopo che 4

5 una scrittura è stata completata, la struttura dati sul disco rimarrà in uno stato inconsistente. 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 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 principale del journaling, una tecnica che aggiunge overhead ad ogni scrittura, ma ripristina più velocemente da errori o mancanza di alimentazione improvvisa. Un sistema transazionale che mira a conservare l integrità di un insieme di dati assicurando che l esecuzioni di operazioni interdipendenti sia completata integralmente oppure totalmente abortita, riportando così il sistema ad uno stato consistente precedente al guasto, come se quest ultimo non si fosse mai verificato. 5

6 Capitolo 1 File System con Journaling: Concetti Generali Il journaling è una delle soluzioni più utilizzate dai moderni file system per preservare l integrità dei dati. La sua caratteristica principale è la capacità di tenere traccia dell evoluzione dello stato del sistema, garantendo in ogni istante la consistenza dell informazioni in esso contenute. Ogni operazione dedicata alla modifica dei dati contenuti sul disco prima di essere ultimata viene annotata su un file speciale detto journal, di solito un log file che viene memorizzato in una particolare area del disco. Il processo di trasferimento dell aggiornamento dei dati dal log file al centro fisso del disco è conosciuto come checkpointing, mentre l operazione che conferma l avvenuto completamento di una transazione è detta commit. Inoltre il journaling file system aggiorna un blocco speciale chiamato journal superblock periodicamente per contrassegnare la dimensione del log file e la fine del checkpointing. In questo modo si garantisce che in caso di crash del sistema o di improvvisa mancanza di alimentazione, durante l aggiornamento del disco, il file system non dovrà far altro che analizzare il log file per determinare quali sono le operazioni che non sono state terminate e inoltre sarà anche in grado di correggere eventuali errori presenti nella struttura del file system, riportando cosi il sistema in uno stato consistente. In base alla progettazione, il journaling aggiunge un ulteriore quantità di lavoro durante la fase di 6

7 aggiornamento ma riduce notevolmente quella necessaria al recupero dei dati. Ad una prima analisi sembrerebbe che questa tecnica sposti il problema dell inconsistenza dal file system al journal stesso; tuttavia ciò 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 integro. 1.1 Modelli di Journaling In base a come si tiene traccia delle transazioni è possibile distinguere due tipi di journaling: Journaling fisico: il sistema registra, nel journal, in anticipo una copia di ogni blocco che sarà poi scritto nel file system principale. Questa tecnica impone una significativa riduzione delle prestazioni poiché ogni blocco modificato deve essere memorizzato due volte, ma può essere utile quando è richiesta una protezione assoluta contro i guasti. Journaling logico: il sistema memorizza solo le modifiche ai metadati del file, nel journal, e tollera gli errori per migliorare notevolmente le prestazioni in scrittura. Cosi come quello fisico questa tecnica permette di recuperare rapidamente dopo un guasto, ma potrebbe causare un errata sincronizzazione tra file di dati non annotati e metadati annotati, danneggiando cosi i dati. Invece considerando cosa viene salvato effettivamente all interno del journal abbiamo tre differenti tipi di journaling: data journaling, ordered jounaling e writeback journaling. Queste diverse modalità di journaling differiscono tra di loro dal tipo di integrità prevista, dal tipo di dati che scrivono nel log file e dall ordine in cui questi vengono scritti. Quello che garantisce una maggiore integrità dei dati è il data journaling. Ogni blocco che viene scritto sul disco, indipendentemente che si tratta di un blocco dati o metadati, viene prima memorizzato nel log file. Una volta che la transazione è stata ultimata, i dati 7

8 possono essere scritti nelle loro posizioni del file system fisso. Il writeback journaling registra soltanto i metadati del file system, mentre i blocchi dati vengono scritti nelle loro locazioni, senza che vi sia ordine tra le due operazioni. In questo modo si garantisce la consistenza dei metadati e non quella dei dati. In particolare, se i metadati di un file vengono aggiornati prima dei dati, il file conterrà i dati del vecchio contenuto di tale blocco. L ordered journaling aggiunge la consistenza dei dati alla modalità writeback. Tale stato viene raggiunto applicando un vincolo di ordinamento nella scrittura (chiamato ordered data writes ), in modo che i blocchi di dati vengano scritti nelle loro postazioni fisse prima della registrazione dei blocchi dei metadati. Assicurando cosi che nessun file system punti a dati corrotti. Quindi ognuna di queste modalità di journaling differisce dall altra dal tipo di dati che sono annotati e dall ordine in cui sono scritti i blocchi. Per definire al meglio le caratteristiche di queste diverse modalità, vengono costruiti dei modelli specificando il tipo di dati che accettano e l ordine in cui questi devono essere scritti. Per esempio, il modello per l ordered journaling specifica che i dati devono essere scritti prima che i metadati vengono scritti nel log file. Innanzitutto si costruiscono delle espressioni regolari per ogni modalità di journaling, poiché queste rappresentano le diverse funzionalità di journaling in modo conciso e sono facili da costruire e capire. Dopodiché si costruisce un modello basato su tale espressione regolare, costituiti da diversi stati che rappresentano lo stato del file system su disco. Quest ultimo si sposta da uno stato all altro in base al tipo di scrittura ricevuta dal file system. Si tiene traccia di tale cambiamento di stato spostandosi corrispondentemente nel modello. L espressioni regolari, descritte successivamente per ogni modalità di journaling, possono essere composte da diversi parametri, come, J che rappresenta la scrittura nel journal, D la scrittura dei dati, C il commit, S la scrittura del superblock, K la scrittura dei dati di checkpoint e F gli eventuali errori di scrittura. 8

9 1.1.1 Data Journaling Il journaling dei dati è rappresentato dalla seguente espressione regolare: ((J + C) + (K * S *) *) +. In questa modalità, tutte le scritture del file system sono annotate (rappresentato da J) e non ci sono scritture ordinate e non ordinate. Dopo aver scritto uno o più blocchi nel journal, viene scritto un ulteriore blocco (rappresentato da C) dal file system per indicare la fine della transazione. Il file system potrebbe scrivere una o più transazioni nel log file. Una volta che le transazioni sono state ultimate, il file system potrebbe scrivere i blocchi di checkpoint (rappresentati da K) alle loro locazioni fisse oppure il journal superblock (rappresentato da S) per indicare la nuova testa e coda del journal. Il modello di tale espressione è descritto dal seguente diagramma di stato, dove è stato aggiunto un ulteriore stato (S3) nel caso di eventuali errori (rappresentati da F). Legenda per la descrizione del modello J: scrittura nel journal dei blocchi dati/metadati C: scrittura del blocco di commit K: scrittura del blocco di checkpoint S: scrittura del journal superblock F: errore di scrittura 9

10 1.1.2 Ordered Journaling Il journaling ordinato può essere descritto dalla seguente espressione regolare: ( ( ( D * J + D *) + C ) + ( K * S *) *) +. In modo ordinato, i blocchi dei dati (D) devono essere scritti prima che i blocchi dei metadati siano scritti nel journal. Si noti che i blocchi dei dati possono essere rilasciati in parallelo con la scrittura del journal (J) ma tutte queste operazioni devono essere completate prima che il blocco (C) che certifica il completamento della transazione sia scritto. Quando il blocco C viene scritto allora la transazione è finita. Cosi come nel data journaling anche in questo caso potrebbero esserci una o più di tali operazioni e inoltre il file system può scrivere i blocchi di checkpoint (K) o il journal superblock (S) dopo le transazioni. Tale espressione regolare viene convertita nel diagramma di stato corrispondente dove viene aggiunto un terzo stato (S3) per eventuali errori, come mostrato in figura 2. Legenda per la descrizione del modello D: scrittura nel disco dei blocchi dati J: scrittura nel journal dei blocchi metadati C: scrittura del blocco di commit K: scrittura del blocco di checkpoint S: scrittura del journal superblock F: errore di scrittura 10

11 1.1.3 Writeback Journaling Il writeback journaling è definito dalla seguente espressione regolare: (((D * J + D *) + C) + (K * D * S *) *) +. In questo modo, i dati (D) possono essere scritti in qualsiasi momento dal file system. Questi possono essere scritti prima o dopo le scritture nel journal ( J ), e solo quando quest ultime sono state completate allora viene scritto il blocco di completamento (C). Anche in questo caso dopo che le transazioni sono state ultimate, il file system può scrivere il journal superblock (S) o i blocchi di checkpoint (K) oppure, a differenza delle altre due modalità, si possono scrivere dei blocchi dati non ordinati (D). Il modello è ottenuto da questa espressione regolare con l aggiunta di un terzo stato (S3) per eventuali errori, ed è mostrato nella figura 3. Legenda per la descrizione del modello D: scrittura nel disco dei blocchi dati J: scrittura nel journal dei blocchi metadati C: scrittura del blocco di commit K: scrittura del blocco di checkpoint S: scrittura del journal superblock F: errore di scrittura 11

12 1.1.4 Confronto tra le modalità di journaling Da una prima analisi effettuata sui modelli delle tre modalità di journaling predefinite, si riscontra che l ordered journaling è quella che garantisce un miglior equilibrio tra performance e affidabilità. Tale stato viene raggiunto scrivendo nel journal solo i blocchi dei metadati in modo che questi siano scritti dopo che i corrispondenti blocchi dei dati vengano salvati sul disco, riducendo così la possibilità di corruzione dei file durante le operazioni di modifica. In generale questa modalità ha prestazioni leggermente più lente del writeback journaling ma significativamente più veloce di un journaling eseguito su tutti i dati. D altronde le migliori prestazioni si ottengono con il writeback journaling, in quanto, come evidenziato nel modello, permette di scrivere i blocchi dei dati in qualsiasi momento aumentando la velocità delle operazioni ma riducendo la correttezza semantica delle informazioni perché sebbene mantiene la consistenza dei metadati non da nessuna certezza sui blocchi di dati regolari. Mentre la più sicura e affidabile è la modalità data journaling poiché memorizza nel journal sia i blocchi dei dati che dei metadati minimizzando la possibilità di perdere le modifiche effettuate. Ciò implica più accessi al disco dato che la scrittura di ogni blocco di dati regolari avviene due volte, la prima sul journal, la seconda definitivamente sulle strutture di memoria preposte, per questo motivo tale modalità viene considerata la più onerosa in termini di prestazioni. In conclusione possiamo affermare che la scelta tra le tre modalità di journaling per una determinata partizione diventa di particolare importanza a seconda dell utilizzo per cui questa viene deputata. 12

13 1.2 Log-Structured File System Non tutti i file system utilizzano la tecnica del journaling per risolvere il problema della consistenza dei dati. Infatti un approccio secondario è definito all interno del file system sviluppato dal professor John Ousterhout e il laureato Mendel Rosenblum noto come LFS, acronimo di Log-structured File System. Il loro progetto si è basato sulle seguenti osservazioni: L aumento delle dimensioni della memoria: più la memoria cresce, più i dati possono essere immagazzinati nella memoria. Poiché i dati vengono memorizzati, il traffico su disco consisterebbe sempre più di scritture, mentre le letture sarebbero assistite nella cache. Pertanto, la prestazione del file system sarebbe in gran parte determinata dalla performance in fase di scrittura. Un grande e crescente divario tra le prestazioni di I/O casuale e prestazioni di I/O sequenziale: quindi, riuscendo ad utilizzare i dischi in maniera sequenziale, si ha un enorme vantaggio prestazionale crescente nel tempo. Un insufficiente rendimento su carichi di lavoro comune da parte degli attuali file system: infatti, alcuni di questi eseguono un gran numero di scritture per creare un nuovo file dalla dimensione di un blocco (uno per un nuovo inode, uno per aggiornare la bitmap inode, uno per la directory del blocco dati, uno per la directory inode, uno per il nuovo blocco dati che è distante dal nuovo file e uno per la bitmap dei dati per indicare il blocco dati come allocato). Così, anche se tutti questi blocchi venissero collocati all interno dello stesso gruppo, il file system andrebbe in contro a ritardi di rotazione e prestazioni scadenti. Per un file system ideale quindi sarebbe meglio concentrarsi sulle prestazioni in scrittura, cercando di utilizzare la larghezza di banda sequenziale del disco. Inoltre, potrebbe funzionare bene su carichi di lavoro comune che non 13

14 scrivono solo dati, ma che aggiornano frequentemente anche le strutture dei metadati sul disco. Quando si scrive su disco, LFS prima bufferizza tutti gli aggiornamenti (inclusi i metadati) in un segmento di memoria, quando questo è pieno, viene effettuato il trasferimento sequenziale su una zona inutilizzata del disco, cioè LFS non sovrascrive i dati esistenti ma piuttosto scrive i segmenti in una parte libera del disco. Dato che i segmenti sono di grandi dimensione, l utilizzo del disco è molto efficiente e quindi le prestazioni del file system si avvicinano al massimo delle prestazioni del disco. Quindi la caratteristica principale del Log-Structured File System è la scrittura sequenziale sul disco, questo significa che ogniqualvolta vogliamo scrivere un blocco dati sul disco dobbiamo affiancare a questo il corrispondente inode e memorizzare il tutto in maniera sequenziale. Purtroppo la scrittura in sequenza su disco non è sufficiente a garantire scritture efficienti. Infatti, tra una scrittura e l altra il disco ruota, ciò comporta un ulteriore ritardo prima che la scrittura può essere ultimata. Proprio per questo motivo LFS utilizza la tecnica del write buffering, ovvero prima di effettuare la scrittura sul disco, vengono registrati gli aggiornamenti nella memoria e solo una volta che si è raggiunto un numero sufficiente, LFS li memorizza sul disco tutto in una volta raggiungendo cosi una maggiore efficienza. Il blocco di aggiornamenti che LFS scrive in una volta sola sul disco viene indicato con il nome di segmento Gestione dei file Oltre al meccanismo principale, LFS include una serie di politiche volte a determinare sia quando cancellare e sia quali blocchi possono essere cancellati. Determinare quando cancellare risulta essere molto più semplice, in quanto tale procedura può avvenire, periodicamente, durante il periodo di inattività oppure perché il disco è pieno. Invece, determinare quali blocchi possono essere cancellati è più complicato. Una prima soluzione proposta per risolvere il problema è stata quella di dividere i blocchi in caldi e freddi. Un 14

15 blocco si dice caldo quando è frequentemente sovrascritto, quindi, per questo la politica migliore è quella di aspettare a lungo prima di essere cancellato. Al contrario un blocco si dice freddo quando questo può avere alcune parti inutilizzate ma il resto dei suoi contenuti sono relativamente stabili. In conclusione si dovrebbero prima cancellare i blocchi freddi e poi quelli caldi, tuttavia questo è solo uno dei tanti approcci che possono essere utilizzati per la gestione dello spazio del segmento La Garbage Collection La gestione dello spazio libero è un altro problema posto al Log-Structured File System. In LFS una sovrascrittura non cancella i dati precedentemente memorizzati, ma semplicemente li invalida. Quando il log riempie interamente il supporto di memoria, LFS ha due possibilità: Utilizzare sempre lo spazio dei blocchi come un log circolare, ma saltando i record fisici validi, ottenendo il cosiddetto log filettato. Soluzione che alla lunga frammenta il log spezzando la sequenzialità delle scritture. Prevedere un algoritmo di deallocazione dei record fisici invalidi, detto algoritmo di recupero dei rifiuti o di garbage collection, che li renda nuovamente disponibili. A tale scopo, i record fisici vengono raggruppati in segmenti, in modo che l algoritmo analizzi un segmento alla volta e se tutti i record fisici contenuti al suo interno sono invalidi allora si può deallocare l intero segmento. D altra parte per garantire che le scritture siano sempre sequenziali, bisogna mantenere lo spazio libero successivamente alla coda del log, deallocando il segmento in testa al log, la quale indica l inizio del log e di conseguenza la fine dello spazio libero, anche se questo segmento contiene qualche record fisico valido. In tal caso, il segmento che si intende reclamare deve essere reso invalido riscrivendo i record fisici ancora validi in coda al 15

16 log. Così il segmento riscritto risulta compatto, dato che i record fisici invalidi non vengono riscritti, perciò questa tecnica è detta di copia e compattazione. Lo svantaggio, introdotto per mantenere la sequenzialità, è l elevato overhead causato dall algoritmo di garbage collection, che può reclamare anche segmenti aventi tutti i record fisici validi. Si può ulteriormente modificare l algoritmo di copia e compattazione rimuovendo il vincolo di dover reclamare sempre il primo segmento in testa al log. In questo modo si ammette maggiore discrezionalità per l algoritmo di garbage collection nella scelta ottimale del segmento da reclamare. Le politiche più utilizzate per effettuare tale scelta sono: La politica greedy, che dealloca sempre il segmento con il minor numero di record fisici validi fra tutti quelli del log Differenziare il trattamento dei segmenti a seconda dei dati che contengono, per quelli contenenti dati caldi conviene aspettare che molti record fisici diventino invalidi prima di reclamarli, mentre per quelli contenenti dati freddi conviene procedere alla revoca immediatamente in modo da non sprecare lo spazio libero dovuto ai record fisici invalidi in esso presenti. 16

17 Con riferimento agli HDD, tale tecnica riduce notevolmente le prestazioni in scrittura a causa dell aumento dell overhead causato dalla garbage collection, mentre per gli SSD tutto ciò può essere vantaggioso, infatti tale algoritmo può essere demandato ad attività di background senza diminuire troppo la performance in scrittura Ripristino e log file Durante il normale funzionamento, LFS bufferizza le scritture in un segmento e poi (quando il segmento è pieno o quando è trascorsa una certa quantità di tempo), scrive il segmento sul disco. LFS organizza queste scritture in un log file, dove la regione di checkpoint punta alla testa e alla coda del segmento e ogni segmento punta al segmento successivo per essere scritto. Inoltre LFS aggiorna periodicamente la regione di checkpoint. Quindi come fa LFS a gestire gli eventuali arresti che possono avvenire durante la scrittura di una di queste strutture? Nel caso in cui l arresto avviene durante la creazione del checkpoint region (CR), LFS memorizza due CR una a ciascuna estremità del disco e scrive loro alternativamente. Inoltre, questo implementa anche un protocollo per l aggiornamento del CR avente l ultimo puntatore alla mappa inode e ad altre informazioni; in primo luogo scrive un intestazione (con timestamp), poi il corpo del CR e infine un ultimo blocco(con un altro timestamp). Se il sistema va in crash durante questo tipo di aggiornamento, LFS è in grado di rilevarlo in quanto nota una coppia incoerente di timestamp, quindi si cerca sempre di utilizzare la più recente CR che ha timestamp coerenti, raggiungendo così un aggiornamento costante del CR. Mentre nel caso in cui ci sia un errore durante la scrittura di un segmento, LFS cerca di recuperare molti di questi con una tecnica utilizzata molto nei database, ovvero iniziare con l ultima regione di checkpoint, trovare la fine del log, utilizzandola per leggere i segmenti successivi e vedere se ci sono aggiornamenti validi all interno di esso. Se ci sono, si aggiorna il file system, 17

18 recuperando così gran parte dei dati e dei metadati scritti dall ultimo checkpoint. In conclusione notiamo che LFS risulta essere un evoluzione rispetto al concetto di journaling, poiché non viene utilizzato un log all interno del file system per le operazioni e quindi per la duplicazione di ogni modifica ma l intera partizione viene vista come un grande log file in cui le modifiche vengono scritte alla fine di questo. Anche per questo motivo LFS è una soluzione ideale per i dischi a stato solido (SSD) dato che questi si basano sul concetto che le letture sono rapide e le scritture lente e che queste ultime avvengono per grossi blocchi di dati contigui a prescindere dalla dimensione dei dati stessi. 18

19 Capitolo 2 File System con Journaling nei sistemi operativi Linux e Windows In questo capitolo, tratteremo i file system principali che utilizzano la tecnica del journaling, argomentando sia quelli che appartengono alla famiglia ext2/ext3/ext4 di Linux sia il file system NTFS di Windows. Descrivendo per ognuno le caratteristiche principali e il tipo di journaling offerto, in modo da poter confrontarli e verificare differenze e similitudini tra essi. 2.1 Ext2 Il secondo file system esteso (Ext2) è stato originariamente rilasciato nel gennaio del 1993, oltre a contenere nuove caratteristiche è molto efficiente e robusto ed insieme alla sua versione successiva (Ext3) è il file system Linux più utilizzato. Ci sono anche implementazioni disponibili per Windows 95/98/NT, OS/2 e RISC OS. Le caratteristiche che contribuiscono a rendere il file system Ext2 molto efficiente sono le seguenti: Quando si crea il file system Ext2, l amministratore del sistema può scegliere la dimensione ottimale del blocco (da a byte), a seconda della lunghezza media del file. Per esempio, si sceglie un blocco da byte quando la lunghezza media del file è più piccola di qualche migliaia di byte, riducendo così la frammentazione interna, a 19

20 meno di una mancata corrispondenza tra la lunghezza del file e la porzione di disco che lo memorizza. Mentre la scelta di blocchi dalle dimensioni maggiori sono preferibili per i file superiori a poche migliaia di byte dato che ciò comporta un minor numero di trasferimenti su disco, riducendo così il sovraccarico di sistema. Per di più l amministratore del sistema può anche decidere quanti inode utilizzare per una partizione di una data dimensione, a seconda del numero medio di file che devono essere memorizzati. In tal modo si massimizza lo spazio su disco effettivamente utilizzabile. Ext2 suddivide i blocchi in gruppi. Ogni gruppo contiene blocchi dati e gli inode memorizzati in tracce adiacenti. Le informazioni relative a ciascun gruppo di blocchi sono conservate all interno di una tabella dei descrittori nel blocco subito dopo il superblock. L algoritmo di allocazione dei blocchi tenta di allocare i blocchi dei dati nello stesso gruppo come gli inode che li contiene. Grazie a questa struttura, si può accedere a file memorizzati in un unico gruppo con un tempo di ricerca minimo. Inoltre il file system alloca blocchi di dati sul disco prima che questi siano effettivamente utilizzati. Così quando il file cresce di dimensione, diversi blocchi già sono allocati in posizioni fisicamente adiacenti, riducendo in questo modo la frammentazione del file. Inoltre il file system Ext2 include altre caratteristiche che lo rendono robusto e flessibile, tra cui: Un attenta realizzazione degli aggiornamenti dei file che minimizza l impatto con eventuali crash di sistema. Ad esempio, quando si crea un nuovo link per un file viene incrementato prima il contatore dei link nel disco inode e poi il nuovo nome viene aggiunto nella directory successiva. In questo modo, se si verificasse un errore dopo l aggiornamento dell inode ma prima che la directory venga modificata 20

21 allora risulta che quest ultima è consistente anche sei il contatore dei link degli inode è sbagliato. L eliminazione del file non porta a risultati catastrofici anche se i blocchi dati del file non possono essere recuperati automaticamente. Invece se avvenisse il contrario, lo stesso guasto produrrebbe una pericolosa incoerenza tra il nuovo file e un inode inesistente. Un supporto per i controlli di coerenza automatici sullo stato del file system al momento del boot. I controlli sono eseguiti da un programma esterno (e2fsck), che può essere attivato non solo dopo errori di sistema ma anche dopo un predefinito numero di montaggi del file system oppure dopo un periodo di tempo dall ultimo controllo effettuato Struttura dati Il primo blocco di ogni partizione non è mai gestito dal file system Ext2 stesso, perché è riservato per il settore di avvio della partizione. Il resto della partizione, come abbiamo sottolineato precedentemente, è diviso in gruppo di blocchi ciascuno dei quali è configurato così come mostrato in figura 5. Alcune strutture dati devono adattarsi esattamente in un blocco mentre altre possono richiedere più di un blocco, inoltre tutti i gruppi di blocchi hanno la stessa dimensione e sono memorizzati sequenzialmente, in modo che il kernel può ricavare la locazione del gruppo nel disco semplicemente dal suo indice intero. 21

22 La suddivisione di blocchi in gruppi riduce la frammentazione dei file, perché il kernel cerca di memorizzare i blocchi dei dati appartenente ad un file nello stesso gruppo. Ogni blocco contiene le seguenti informazioni: Una copia del superblock del file system Una copia del gruppo di descrittori del gruppo di blocchi Un blocco dati bitmap Un inode bitmap Una tabella di inode I blocchi dei dati Se un blocco non contiene nessuna di queste informazione allora tale blocco si dice libero. Inoltre come si può notare dalla figura 5 sia il superblock sia il gruppo di descrittori vengono duplicati in ogni gruppo di blocchi, in modo da garantire la stabilità del sistema. Infatti, solo nel caso in cui vengono danneggiati il superblock e il gruppo di descrittori memorizzati nel blocco principale, l amministratore di sistema può effettuare il controllo e2fsck riferendosi ai loro duplicati. Di solito, le copie ridondanti memorizzano informazioni sufficienti per consentire a e2fsck di riportare Ext2 in uno stato consistente. 22

23 2.1.2 Funzionalità aggiuntive di Ext2 Il file system Ext2 così come evidenziato risulta essere un programma maturo e stabile, inoltre sono state prese in considerazione alcune funzionalità aggiuntive molto importanti. Alcune di queste sono state codificate e rese disponibili come patch esterne, altre sono state solo pianificate. Le più significative sono: La frammentazione dei blocchi: la quale può essere risolta consentendo a diversi file di essere memorizzati in frammenti diversi di uno stesso blocco. Gestione dei file compressi e crittografati: queste opzioni consentono agli utenti di memorizzare versioni compresse e/o cifrate dei propri file sul disco. Eliminazione logica: opzione che consente di recuperare facilmente, se necessario, il contenuto di un file precedentemente rimosso. Journaling: la prima estensione in Ext2 fu quella sviluppata da Stephen Tweedie. Questa versione evita i rischi di danneggiamento dei metadati e la necessità di attendere il completamento di e2fsck dopo un crash, senza richiedere una modifica di Ext2 su disco. Cioè il journal è un file regolare dove vengono memorizzati tutti i blocchi dei metadati modificati prima che vengono scritti nel file system. In pratica, nessuna di queste caratteristiche è stata ufficialmente inclusa in Ext2 ma quella che suscita più scalpore è la mancanza del journaling che è richiesto dai server ad alta disponibilità. Questo motivo ha portato allo sviluppo di una nuova versione, Ext3, compatibile con la precedente e che offre anche il journaling in modo da poter soddisfare tutti gli utenti. 23

24 2.2 Ext3 Il file system Ext3 è un evoluzione della versione precedente, Ext2. Il nuovo file system è stato progettato per due semplici motivi: Essere un file system journaling Essere, per quanto possibile, compatibile con il vecchio file system Ext2 Entrambi gli obiettivi vengono raggiunti molto bene. In particolare, Ext3 è in gran parte basato su Ext2, quindi le sue strutture dati sono sostanzialmente identiche a quelle della precedente versione. In questo modo, se un file system Ext3 viene smontato questo può essere rimontato come un file system Ext2; al contrario, creando un journal in Ext2 e rimontarlo in Ext3 è un operazione semplice e veloce. Grazie alla compatibilità tra le due versioni, la maggior parte delle caratteristiche descritte nella sezione precedente vengono applicate anche per Ext3, pertanto, in questa sezione verrà descritta la nuova funzionalità offerta da Ext3, il journaling Il Journaling in Ext3 L idea alla base del journaling nel file system Ext3 è quella di eseguire le modifiche ad alto livello in due fasi. In primo luogo, una copia dei blocchi da scrivere è memorizzata nel journal, poi, soltanto quando questa operazione è stata completata allora i blocchi vengono scritti nel file system. Una volta che i blocchi sono stati trasferiti dal journal al file system, le rispettive copie vengono eliminate. Durante il recupero dei dati dovuto ad un errore di sistema, e2fsck distingue i due casi seguenti: L errore è avvenuto prima dell operazione di commit: quindi e2fsck ignora sia le copie dei blocchi relativi alla variazione di alto livello mancanti nel journal, sia quelli incompleti. 24

25 L errore si verifica dopo l operazione di commit: in questo caso le copie dei blocchi sono valide e e2fsck le scrive nel file system. Nel primo caso, la variazione ad alto livello nel file system è persa, ma lo stato è ancora consistente. Nel secondo caso, viene effettuata l intera variazione ad alto livello che fissa così ogni inconsistenza dovuta ad un incompiuto trasferimento dei dati nel file system. Di solito, il file system con journaling non copia tutti i blocchi nel journal. Infatti, ogni file system è costituito da due tipi di blocchi, quelli contenenti i cosiddetti metadati e quelli contenenti i dati regolari. Nel caso dei file system Ext2 e Ext3 ci sono sei tipi di metadati: i superblock, il gruppi dei blocchi descrittori, gli inode, i blocchi utilizzati per l indirizzamento indiretto, i blocchi dati bitmap e i blocchi inode bitmap. Alcuni file system che utilizzano il journaling decidono di registrare soltanto i metadati, dato che questi sono sufficienti per ripristinare la consistenza delle strutture dati sul disco nel file system. Tuttavia, Ext3 può essere configurato per registrare le operazioni che interessano sia i metadati che i dati dei file. Ma poiché la registrazione di ogni tipo di operazione di scrittura comporta una sensibile riduzione delle prestazioni, Ext3 consente all amministratore di sistema di decidere cosa deve essere registrato, e in particolare offre tre diverse modalità: Journal: tutte le modifiche apportate ai dati e metadati del file system vengono registrate nel journal. Questa modalità minimizza la possibilità di perdere gli aggiornamenti apportati ad ogni file, ma richiede molti accessi al disco, per questo viene considerata la più sicura e la più lenta. Ordered: vengono registrate solo le modifiche apportate ai metadati del file system. Tale operazione viene effettuata in modo che i blocchi di dati vengono scritti prima dei blocchi metadati sul disco, garantendo così una riduzione della possibilità di avere un danneggiamento dei dati 25

26 all interno del file. Questa è la modalità predefinita del journaling in Ext3. Writeback: solo i cambiamenti ai metadati del file system sono registrati nel journal. Durante il ripristino può presentare dati non corretti nei file che sono stati scritti poco prima dell errore. Questa modalità fornisce in genere la migliore prestazione in Ext3. La modalità di journaling del file system Ext3 è specificata da un opzione nel comando di montaggio del sistema. Per esempio, se si vuole montare il file system Ext3, con modalità writeback, memorizzato nella partizione /dev/sda2 in /jdisk, l amministratore di sistema può digitare il comando: # mount -t ext3 -o data=writeback /dev/sda2 /jdisk Journaling Block Device Il journal Ext3 è di solito memorizzato in un file nascosto di nome.journal collocato nella directory principale del file system. D altronde Ext3 non gestisce il journal propriamente, ma utilizza un livello del kernel generale chiamato Journaling Block Device, o meglio JBD. Questa routine viene richiamata per garantire che le successive operazioni non corrompano le strutture dati su disco in caso di guasti al sistema. Tipicamente, JBD, utilizza lo stesso disco per registrare le modifiche effettuate dal file system Ext3, ed è pertanto vulnerabile a guasti di sistema tanto quanto Ext3. Quindi, JBD deve proteggersi da errori di sistema che potrebbero danneggiare il journal. L interazione tra Ext3 e JBD si basa essenzialmente su tre unità fondamentali: Log record: essenzialmente è la descrizione di un operazione di basso livello che sta per essere rilasciata dal file system. Lo strato JBD utilizza i log record costituiti da tutto il buffer modificato dall operazione di basso livello. Questo approccio può sprecare molto 26

27 spazio del journal, ma è molto veloce perché JBD può lavorare direttamente con i buffer e la testa del buffer. Inoltre, questi sono rappresentati all interno del journal come normali blocchi dati/metadati e ad ognuno è associato un tag del tipo journal_block_tag_t, che memorizza il numero del blocco logico all interno del file system e alcuni indicatori di stato. Atomic operation handle: questa operazione garantisce al file system Ext3 che ogni tipo di system call venga gestita in maniera atomica evitando così il danneggiamento dei dati. Un operazione atomica è un insieme di operazioni di basso livello sulle strutture dati del disco che corrisponde ad una singola operazione di alto livello. Per avviare questo tipo di operazione, il file system Ext3 richiama alcune funzioni del JBD le quali assicurano che venga applicata l intera operazione ad alto livello o nessuna delle sue operazioni a basso livello. Transaction: il JBD, per ragioni di efficienza, gestiscono il journal raggruppando i log record appartenenti a diverse operazioni atomiche in una singola transazione. Inoltre, ogni log record relativo ad una stessa operazione deve essere incluso nella medesima transazione e memorizzato in blocchi consecutivi del journal. Una transazione si dice completa quando tutti i log record sono stati fisicamente scritti nel journal, in modo che durante un recupero e2fsck possa considerare ognuna di queste e scrivere i blocchi corrispondenti nel file system e soltanto quando il JBD verifica che tutti i buffer sono stati scritti con successo nel file system Ext3 allora questa può essere eliminata dal journal. Mentre una transazione è detta incompleta quando almeno un log record non è stato ancora scritto nel journal, in tal caso e2fsck le ignora completamente. 27

28 2.3 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, introducendo diverse caratteristiche aggiuntive, tra le quali il meccanismo di checksumming, capace di rafforzare l integrità dei dati. Esattamente come Ext3, anche Ext4 supporta le tre modalità di journaling (data, ordered, writeback) applicate ai blocchi. Come già accennato, ciò comporta un maggior grado di affidabilità, a discapito di un elevato overhead dato che 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 nel journal dell intero blocco, contenente anche gli inode vicini non implicati nell operazione. Inoltre Ext4 nasce anche per lo scopo di aumentare i limiti di immagazzinamento a 64 bit di Ext3, infatti questo supporta file grandi massimo 2 TB e file system grandi complessivamente 32 TB. Invece ext4 usa 48 bit per l'indirizzamento dei blocchi, quindi i limiti aumentano: si potranno avere file grandi fino a 16 TB, ed i file system potranno essere grandi fino 1 EB. Il motivo dell'utilizzo di 48 bit è dettato da alcune limitazioni che dovrebbero essere superate prima di poter portare l'indirizzamento dei blocchi di ext4 a 64 bit; tali correzioni tuttavia non rientrano nella pianificazione di ext4. Le strutture di ext4 sono state progettate prendendo in considerazione questo concetto, quindi un futuro aggiornamento di ext4 implementerà il completo supporto all'indirizzamento a 64 bit. 1 EB è tuttavia sufficiente finché questo non accadrà Struttura ed utilizzo del journal Il journal Ext4 è un file residente all interno del file system, avente la possibilità di essere memorizzato anche su un diverso supporto. Il journal è strutturato in blocchi di diversa tipologia: 28

29 Superblock, che conserva le informazioni sul journal stesso, come la dimensione dei blocchi di cui è composto; il numero totale di blocchi a disposizione; la locazione iniziale del journal; il numero di sequenza della prima transazione e la rispettiva locazione in memoria. Descriptor block, ogni transazione contiene una descrizione delle locazioni finali dei blocchi dati che seguono nel journal. Metadata block, all interno dei quali vengono registrate le modifiche apportate al sistema. Nel caso del data journaling, tali blocchi rispecchiano anche i dati coinvolti nella scrittura. Commit block, che indica la terminazione di una transazione effettuata con successo. Revoke block, contenente la lista dei blocchi che non dovrebbero essere riscritti nel file system, come quando avviene una dipendenza ciclica tra due transazioni ed una di essa non è stata ancora confermata nel journal. In ogni caso tali blocchi possono essere scritti sul disco se il sequence number è più alto rispetto a quello del revoke block. Tutti i blocchi descritti, esclusi i metadati, vengono detti blocchi amministrativi e condividono nei primi 12 byte un header di struttura uguale. Il sistema tratta tutte le operazioni in esecuzione come un unica transazione globale. Ciò nonostante si rifletta in un miglioramento delle prestazioni, è 29

30 possibile che dia luogo a raggruppamenti di operazioni incoerenti, che possono portare ad un intreccio tra traffico sincrono ed asincrono nel file system. Inoltre le politiche di commit e di checkpoint variano in base a tre fattori: richiesta di sincronizzazione da parte di un applicazione; dimensione del diario e 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 scritture ad esso applicate. Per di più rende una maggiore efficienza nelle operazioni di annotazione del sistema, introducendo sostanziali miglioramenti delle performance. In Ext3 e Ext4, ogni transazione del journal ha un blocco header e un blocco di commit. Durante il normale funzionamento del journal il blocco di commit non viene inviato al disco fino a quando il blocco header e tutti i blocchi metadati non sono stati ancora scritti nel disco, e l operazione successiva deve attendere che il precedente blocco di commit sia scritto nel disco prima di poter cominciare a modificare il file system. Con questa operazione di commit a due fasi, se il blocco di commit ha lo stesso numero di transazione del blocco header, allora tale transazione può essere riprodotta in fase di ripristino, altrimenti, se non dovessero corrispondere il ripristino del journal terminerebbe. Tuttavia ci sono alcuni scenari dove questo tipo di operazione può fallire e corrompere così il file system. Invece, aggiungendo il checksumming al journal viene calcolato un CRC32 su tutti i blocchi della transazione (incluso il blocco header), e il checksum viene scritto nel blocco di commit. In questo modo, se il checksum non corrisponde in fase di ripristino, allora vuol dire che uno o più blocchi dei metadati di quella transazione sono danneggiati o non sono stati scritti sul disco. Così, la transazione viene scartata come se si fosse verificato un errore poco prima e non sia stato scritto nessun blocco di commit. Dal momento che 30

31 il checksum permette di individuare i blocchi che non sono stati scritti nel journal, non c è più la necessità di avere un commit a due fasi per ogni transazione. Così, il blocco di commit può essere scritto contemporaneamente al resto dei blocchi della transazione. Questa tecnica velocizza sensibilmente le prestazioni del file system (fino al 20%), contrariamente a quanto potrebbe far intuire l introduzione di overhead Altre caratteristiche Oltre al checksumming, un altra caratteristica che aiuta ad aumentare le performance del file system è l allocazione multiblocco. Nella versione precedente, Ext3 può allocare solamente un blocco (4KB) alla volta, dato che il meccanismo di allocazione non è in grado di sapere quanti blocchi il sistema vuole allocare, sa solamente che gli è stato chiesto di allocare un blocco. Invece con Ext4 e l allocazione multiblocco si possono allocare più blocchi per ogni singola chiamata, limitando molto l overhead ma garantendo più efficienza all operazione senza influenzare il formato dei dati sul disco. Questa caratteristica è particolarmente utile con un altra funzionalità introdotta in Ext4, ovvero l allocazione ritardata. Sviluppata soprattutto per migliorare le prestazioni in fase di scrittura, con questo metodo l allocazione dei blocchi avviene in due fasi (prenotazione ed allocazione) in modo tale da mantenere i dati il più possibile nella cache. Molti file infatti hanno vita breve, ed in questo modo è possibile farne uso senza allocarli sul disco. D altronde anche i file più duraturi traggono vantaggio da questa tecnica poiché il kernel ha a disposizione più dati da poter allocare in maniera contigua, riducendo la frammentazione e velocizzando di conseguenza le operazioni di scrittura e lettura. Tuttavia, l allocazione ritardata presenta alcuni effetti collaterali: conservare in maniera prolungata dei dati all interno della cache non fa altro che vanificare gli sforzi compiuti dal meccanismo di journaling per preservarne la consistenza, così favorendo la performance si rischia che la 31

32 scrittura dei metadati anticipi quella dei dati ad essi afferenti contrastando il processo di allocazione ordinata. 2.4 NTFS NTFS, New Technology File System, è stato presentato da Microsoft nel 1993 per il sistema operativo Windows NT 3.1. Nonostante non siano reperibili pubblicamente codice sorgente o documentazione su NTFS, studi di ingegneria inversa hanno delineato la struttura adottata per l implementazione del journaling. Tale file system implementa alcune strategie che migliorano la sua affidabilità. La prima è che la recuperabilità di NTFS garantisce che la struttura del volume non verrà danneggiata, in modo che tutti i file restano accessibili dopo un errore di sistema. La seconda è che nonostante NTFS non garantisce protezioni di dati utente, le applicazioni possono trarre vantaggio dalle funzionalità di write-through e cache-flushing per assicurare che le modifiche ai file vengano registrate sul disco ad intervalli adeguati. Entrambe, write-through costringe le operazioni di scritture ad essere immediatamente memorizzate sul disco e cache-flushing forza i contenuti della cache ad essere scritti sul disco sono operazioni molto efficienti. Inoltre NTFS memorizza le modifiche alle strutture dati con una singola operazione di scrittura in un log file(journal); se si verificasse un errore e i contenuti della cache andassero perduti, le modifiche al file system potrebbero essere recuperate dal log file. Questo è collocato al centro del file system e la sua implementazione 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. 32

33 2.4.1 Log File Service Il Log File Service (LFS) è una serie di routine, effettuate in modalità kernel, che sono situate all interno del driver NTFS il quale le utilizza per accedere al log file. NTFS passa un puntatore a LFS per aprire un file oggetto, che specifica un log file a cui accedere. LFS o inizializza un nuovo log file oppure invita il gestore della cache di Windows ad accedere al log file esistente attraverso la cache, come mostrato in figura 7. Il log file è 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, per esempio come la locazione della logging area dalla quale bisogna iniziare a leggere. Oltre a questa, LFS memorizza anche una seconda copia della restart area, per poter far fronte all ipotizzabile corruzione della prima copia. La logging area è strutturata come una coda circolare, per ciò è detta anche infinite logging area, nella 33

34 quale ogni elemento è contrassegnato da un Log Sequence Number (LSN), e possiede due update record (redo information, undo information). LFS memorizza nella logging area un record per ciascuna sub-operazione che compone una transazione. Tale record contiene le informazioni utili per 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. L implementazione della logging area utilizzando un buffer circolare può portare ad una situazione di saturazione dello stesso. Tale problema è gestito da NTFS tramite l utilizzo di un eccezione volta a bloccare tutte le transazioni 34

35 in atto, che saranno riprese successivamente, e riavvolgere quelle parzialmente completate. Così il sistema può svuotare le proprie cache (journal compreso) sul disco e riprendere le transazioni poste in attesa, sfruttando stavolta un log vuoto Checkpointing Per facilitare l operazione di ripristino, evitando di scorrere l intera logging area, NTFS implementa un meccanismo di checkpoint. Periodicamente NTFS scrive un record di checkpoint nella logging area, ed il suo LSN viene salvato nella restart area. In 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. Tale procedura aiuta NTFS a determinare quale operazione sarebbe necessaria per recuperare un volume se si verificasse improvvisamente un errore. Utilizzando le informazioni memorizzate nel checkpoint record, NTFS conosce quanto indietro bisogna andare nel log file per iniziare il ripristino. 35

36 2.4.3 Ripristino NTFS esegue automaticamente un ripristino del disco la prima volta che un programma accede ad un volume NTFS dopo che il sistema è stato avviato. (Se non è necessario alcun ripristino, tale processo è inutile). Il ripristino dipende da due tabelle che NTFS conserva in memoria: una tabella di transazione, e la così detta dirty page table, che memorizza le pagine della cache che contengono le modifiche alla struttura del file system e che non sono ancora state scritte sul disco. NTFS scrive un record di checkpoint nel log file una volta ogni 5 secondi, ma prima di fare ciò invoca LFS per memorizzare al suo interno una copia corrente della tabella di transazione e della dirty page table. Quando inizia il ripristino dopo un errore di sistema, NTFS invoca LFS per individuare il più recente record di checkpoint e le più recenti copie delle due tabelle. Poi copia le tabelle in memoria. Quindi la procedura di ripristino può essere 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 e recupera le copie della tabella di transazione e la dirty page table Si effettua una fase di redo. Alla fine della quale, la cache riflette lo stato del dispositivo quando è avvenuto il crash. Si effettua una fase di undo. Alla fine della quale il dispositivo è ripristinato ad uno stato consistente. 2.5 Confronto tra i file system analizzati A questo punto sorge spontaneo chiedersi quale delle soluzioni analizzate sia la migliore. Esistono diversi approcci per valutare i file system, uno di questi è quello di effettuare un analisi comparativa (benchmarking) tra diversi file 36

37 system su differenti sistemi operativi che utilizzano il benchmark. Il file system benchmark ideale dovrebbe: Dare la comprensione del perché un sistema esegue quanto fa Essere I/O limitato Consentire il confronto tra le piattaforme Essere rilevante per una vasta gamma di applicazioni Essere ben specificato e riproducibile Sulla base di questi criteri, prendiamo in considerazione lo strumento di benchmark IOzone per valutare le prestazioni di alcuni file system. IOzone è un benchmark puramente sintetico che misura una varietà di operazioni su file, lo utilizziamo per valutare le prestazioni in lettura e scrittura di alcuni file system. Come è possibile notare dalla figura 11, i file system sono stati sottoposti ad un test di lettura di un file di 4GB. Si nota che il file system Ext4 prevale su tutti gli altri, gestendo poco più di 70 Mbyte al secondo. Anche il file system Ext2 gode di un ottimo risultato, mentre Ext3 e NTFS rientrano nei parametri standard per questo tipo di operazione. Invece nella figura 12, i file system sono stati sottoposti ad un test di scrittura per un file dalle stesse dimensioni di quello precedente. 37

38 In questo caso, si osserva che il file system NTFS è molto più svantaggioso rispetto agli altri, infatti, contrariamente alla fase di lettura, questo rallenta esageratamente in fase di scrittura. Ancora una volta la miglior prestazione è stata ottenuta dal file system Ext4, rendendolo così il più efficiente di quelli che sono stati analizzati. In particolare, dai test effettuati si nota che il file system Ext2 risulta essere maggiormente performante rispetto a Ext3 e NTFS, ma ricordiamo che questo non ha il journaling, quindi non garantisce nessuna integrità dei dati a differenza degli altri file system presi in considerazione. Deduciamo così, che la scelta del tipo di file system non dipende solo dalle prestazioni che questo può assicurare ma bisogna considerare soprattutto il trade-off tra la velocità del sistema e la sicurezza dei dati. Conclusioni A conclusione di quanto visto, possiamo dire che la tecnica del journaling è quella più utilizzata dalla maggior parte dei file system per fronteggiare il problema della consistenza dei dati. Tuttavia è comprensibile la difficoltà di poter sostenere un confronto assoluto tra tutti i file system che utilizzano il journaling, a causa della mole di parametri in gioco. Per questo motivo la scelta dei file system analizzati dipende soprattutto dall utilizzo di un determinato dispositivo di archiviazione dati. Infatti, il file system Ext2 38