Tipi di File System e Prestazioni

Transcript

1 Università degli Studi di Salerno Facoltà di Scienze Matematiche Fisiche e Naturali Tesina di Sistemi Operativi Tipi di File System e Prestazioni Prof. Giuseppe Cattaneo Michele Carillo Flavio Serrapica Francesco Milone

2 Indice 1 Introduzione Definizione di File System File e operazioni su file Struttura di una directory File System Log-Structured File System Distributed File System Introduzione Caratteristiche Naming e trasparenza Accesso ai file remoti Uso della cache Servizio Statefull e Servizio Stateless Coerenza Replica Prestazioni DFS Esempi di DFS Andrew File System Generalità Operazioni sui file e semantica della consistenza Spazio dei nomi condiviso Kernel, server e cache manager Network File System Caratteristiche NFS Critiche ad NFS i

3 INDICE Altri tipi di DFS: SMB, CIFS, SAMBA Service Message Block Common Internet File System SAMBA Log-Structured File System Introduzione Progettazione Gestione dello spazio libero Crash Recovery Considerazioni finali Software per il benchmarking di file system IOzone Bonnie Bonnie Randomio PostMark Perchè IOzone? Benchmarking di file system Hardware utilizzato Operazioni sequenziali Scrittura Lettura Operazioni random Scrittura Lettura Bibliografia 107

4 Capitolo 1 Introduzione 1.1 Definizione di File System Il file system è quella parte del sistema operativo che si occupa di gestire e strutturare le informazioni memorizzate sui supporti permanenti(ad esempio: memoria secondaria). Il file system consiste di due parti distinte: un insieme di file, ciascuno dei quali contenente dati correlati una struttura di directory, che organizza tutti i file nel sistema, fornendo informazioni su di essi Alcuni file system hanno un terzo componente: le partizioni, usate per separare fisicamente o logicamente grandi gruppi di directory File e operazioni su file Un file è una collezione di informazioni che deve avere un nome logico. Dal punto di vista dell utente, un file è la più piccola porzione di memoria secondaria logica; i dati si possono scrivere nella memoria secondaria soltanto all interno di un file. Di solito i file rappresentano programmi e dati. Un file ha altri attributi che possono variare a seconda del sistema operativo, ma che tipicamente sono i seguenti: Nome: Si tratta di un identificativo che permette all utente di identificare il file nel sistema tramite un valore alfanumerico 2

5 CAPITOLO 1. INTRODUZIONE 3 Identificatore: Si tratta di un etichetta unica di solito un numero, che identifica il file all interno del file system; non è altro che il nome usato dal sistema per il file Tipo: Questa informazione è necessaria ai sistemi che gestiscono tipi di file diversi Locazione: Si tratta di un puntatore al dispositivo e alla locazione del file in tale dispositivo Dimensione: Si tratta della dimensione corrente del file(usualmente in byte) Ora, data e identificatore dell utente. Tali informazioni sono relative alla creazione, l ultima modifica e l ultimo uso. Questi dati possono essere utili ai fini della protezione e per controllare l uso. Mediante il file system, l utente ha la possibilità di: strutturare i file, organizzandoli secondo le loro caratteristiche proteggere i propri file nel caso ci troviamo ad operare su un sistema multi-utente, ossia avere la possibilità di impedire ad altri utenti di leggerli, copiarli o cancellarli. Un insieme di operazioni minimali, presente in tutti i sistemi, è il seguente: creazione di un file cancellazione di un file copia o spostamento di un file visualizzazione del contenuto di un file stampa di un file modifica del contenuto di un file ridenominazione di un file visualizzazione delle proprietà di un file attraversamento del file system, ossia accedere ad ogni directory ed a ciascun file contenuto in una directory.

6 CAPITOLO 1. INTRODUZIONE Struttura di una directory Il file system di un calcolatore può essere molto ampio. Come detto in precedenza, il file system può essere suddiviso in uno o più partizioni. Le informazioni sui file contenuti in ciascuna partizione sono mantenute negli elementi della directory del dispositivo o tabella contenuti del volume. La directory del dispositivo, semplicemente nota come directory, registra informazioni di tutti i file della partizione. La directory si può considerare come una tabella di simboli, che traduce i nomi dei file negli elementi in essa contenuti. Directory a singolo livello Questa è la struttura più semplice per una directory. Tutti i file sono contenuti nella stessa directory, ciò la rende facilmente gestibile ed intuitiva. Essa presenta limiti notevoli che si manifestano all aumentare del numero di file in essa contenuti, oppure se il sistema è usato da più utenti. Dato che i file si trovano tutti nella medesima directory, i loro nomi devono essere univocamente definiti, quindi per un singolo utente, diventa difficile ricordare i nomi dei file all aumentare del loro numero. Directory a due livelli Nella struttura a due livelli, ogni utente dispone della propria directory utente, la quale è composta dai soli file-utente. Quando un utente inizia una sessione di lavoro, si fa una ricerca nella directory principale del sistema. Tale directory viene indirizzata con il nome dell utente o il numero che lo rappresenta e ogni suo elemento punta alla relativa directory d utente. Quando un utente fa un riferimento a un file particolare, il sistema operativo esegue la ricerca solo nella directory di quell utente. In questo modo utenti diversi possono avere file con lo stesso nome, purché tutti i nomi di file all interno di ciascuna directory utente siano unici. Sebbene risolva il problema delle collisioni dei nomi, la struttura di una directory a due livelli presenta ancora dei problemi. In pratica, accade che questa struttura isola un utente dagli altri utenti. Questo isolamento può essere un vantaggio quando gli utenti sono completamente indipendenti, ma è uno svantaggio quando gli utenti vogliono cooperare ed accedere a file di altri utenti. Una directory a due livelli si può pensare come un albero o almeno un albero rovesciato, di altezza 2. La radice dell albero è la directory principale, i suoi diretti discendenti sono le directory utente, da cui discendono i file che sono le foglie dell albero. Specificando un nome-utente e un nome-file si definisce un percorso che parte dalla radice (la directory principale) e arriva ad una

7 CAPITOLO 1. INTRODUZIONE 5 specifica foglia (il file specificato). Quindi, un nome-utente e un nome-file definiscono un nome di percorso (pathname). Ogni file del sistema ha un nome di percorso. Per attribuire un nome unico ad un file, un utente deve conoscere il nome di percorso del file desiderato. Directory con struttura ad albero La corrispondenza strutturale tra directory a due livelli e albero a due livelli, permette di generalizzare facilmente il concetto, estendendo la struttura di directory ad un albero di altezza arbitraria. Questa generalizzazione permette agli utenti di creare proprie sotto-directory e di organizzare i file di conseguenza. L albero ha una directory radice (root directory), e ogni file del sistema ha un unico nome di percorso(pathname). Un nome di percorso descrive il percorso che parte dalla radice, passa attraverso tutte le sotto-directory, fino ad arrivare ad un file specifico. Una directory, od una sotto-directory, contiene un insieme di file o sotto-directory. Le directory sono semplicemente file, che sono però trattati in modo speciale. Tutte le directory hanno lo stesso formato interno. La distinzione tra file e directory è data dal bit, rispettivamente 0 ed 1, di ogni elemento della directory. Normalmente, ogni utente dispone di una directory corrente, la quale deve contenere la maggior parte dei file di interesse. Quando si fa riferimento ad un file, si esegue una ricerca nella directory corrente; se il file non si trova in tale directory, l utente deve specificare un nome di percorso oppure cambiare la directory corrente facendo diventare tale la directory che contiene il file desiderato. Quindi, l utente può cambiare la propria directory corrente ogni volta che lo desidera I nomi di percorso possono essere di due tipi: nomi di percorso assoluti e nomi di percorso relativi. Un nome di percorso assoluto comincia dalla radice dell albero di directory e segue un percorso che lo porta fino al file specificato, indicando i nomi delle directory che costruiscono le tappe del suo cammino. Un nome di percorso relativo definisce un percorso che parte dalla directory corrente. Directory con struttura a grafo aciclico La struttura ad albero non ammette la condivisione di file o directory. Un grafo aciclico permette alle directory di avere sottodirectory e file condivisi. Lo stesso file o la stessa sottodirectory possono essere in due directory diverse. Un grafo aciclico, cioè senza cicli, rappresenta la generalizzazione naturale dello schema delle

8 CAPITOLO 1. INTRODUZIONE 6 directory con struttura ad albero. Il fatto che un file oppure una directory siano condivisi, non significa che ci siano due copie del file. Se invece il file è condiviso esiste un solo file effettivo, perciò tutte le modifiche sono immediatamente visibili. La condivisione è di particolare importanza se applicata alle sottodirectory; un nuovo file appare automaticamente in tutte le sottodirectory condivise Un collegamento (link) è un puntatore a un altro file o un altra directory. Quando si fa riferimento ad un file, si compie una ricerca alla directory, l elemento cercato è contrassegnato come collegamento e riporta il nome di percorso del file, o della directory, reale. Quindi si risolve il collegamento usando il nome di percorso per localizzare il file reale. Durante l attraversamento degli alberi delle directory il sistema operativo ignora questi collegamenti, preservando così la struttura aciclica della struttura. Quando si crea un collegamento, oppure una copia dell elemento della directory, si aggiunge un nuovo elemento all elenco dei riferimenti al file; quando si cancella un collegamento oppure un elemento della directory, si elimina dall elenco l elemento corrispondente. Se il suo elenco di riferimenti è vuoto si cancella il file. Questo metodo presenta, però, un problema: la dimensione dell elenco dei riferimenti al file può essere variabile e potenzialmente grande. Tuttavia, non è realmente necessario mantenere l intero elenco, è sufficiente un contatore del numero di riferimenti. Un nuovo collegamento od un nuovo elemento decrementa questo numero. Quando il contatore è uguale a 0 si può cancellare il file, poiché non ci sono più riferimenti a tale file.

9 Capitolo 2 File System 2.1 Log-Structured File System Introduzione Il Log-Structured File System (LFS) nasce nel 1992 con l obiettivo di migliorare le performance dello storage dei dati sui dischi, fornendo un nuovo modello di organizzazione e gestione del disco. Tale necessità nacque dall incremento esponenziale delle performance delle CPU, la cui potenza era cresciuta a tal punto da rendere le operazioni di I/O il collo di bottiglia di un sistema. Uno dei principi su cui si basa LFS è quello di mantenere i file nella memoria centrale; in modo da migliorare le performance della lettura, ed ottimizzare la scrittura dei file sfruttando blocchi contigui di memoria libera. I sistemi sarebbero così non più dominati dalle operazioni di I/O, ma solo da operazioni di scrittura effettiva del disco. Una ottimizzazione della operazione di scrittura avrebbe reso l accesso al disco meno gravoso da parte del sistema operativo. LSF effettua la scrittura delle informazioni sul disco utilizzando una struttura sequenziale chiamata log; in tal modo vengono ottimizzate le operazioni di scrittura, evitando di dover effettuare scansioni dell intero disco per la ricerca di informazioni. La natura sequenziale del log permette anche il recupero dai crash in maniera molto veloce: i normali file system senza meccanismo di log necessitano di una scansione intera del disco per ripristinare la consistenza, ma LFS attraverso l utilizzo del log si limita ad esaminare solo la parte finale del log. 7

10 CAPITOLO 2. FILE SYSTEM 8 LFS-Progettazione Log-Structured File System tenta di aumentare le performance, bufferizzando una sequenza di modifiche del file system in un file e successivamente scrivere questi cambiamenti in maniera sequenziale, in una singola operazione di scrittura. Le informazioni scritte sul disco includono file data block, attributi, index blocks, directory e quasi tutte le altre informazioni utilizzate per gestire il file system. Se il flusso di dati da scrivere è composto da molti piccoli file, LFS converte queste piccole scritture sincrone in un unica grande scrittura asincrona in modo da sfruttare tutta la larghezza di banda del disco. Per apportare effettivi benefici in fase di scrittura. Vi sono due problemi chiave da risolvere: gestire lo spazio libero sul disco e gestire il recupero delle informazioni dal file di log. Gestione dello spazio libero: i segmenti La difficoltà principale nella progettazione di LFS è la gestione dello spazio libero. L obiettivo è quello di poter avere a disposizione larghe estensioni di spazio libero per le scritture di nuovi dati. Inizialmente tutto lo spazio libero è rappresentato da una singola estensione sul disco, ma, con il passare del tempo, il log raggiunge la fine del disco e lo spazio libero viene frammentato in tante piccole estensioni corrispondenti ai file che sono stati eliminati o riscritti. A questo punto il file system ha due opzioni: threading o copying. Il threading consiste nel salvare i dati in un luogo sul disco e posizionare il log nelle estensioni restanti. Sfortunatamente il threading causa una fitta frammentazione, inoltre larghe scritture contigue non sono possibili e quindi il Log-Structured File System non risulterebbe più veloce rispetto ai tradizionali file system. La seconda alternativa è quella di copiare i dati al di fuori del log in modo da avere larghe estensioni di spazio libero. Lo svantaggio di questa alternativa consiste nel costo, soprattutto per file longevi. Nel caso più semplice, in cui il log lavora circolarmente sul disco e i dati vengono copiati nel log, tutti i dati già presenti nel log (file longevi) devono essere ricopiati ad ogni aggiornamento del log. In figura 5.1 vengono mostrate le due tecniche. LSF utilizza una combinazione del threading e del copying. Il disco viene diviso in larghe zone con un estensione fissata, le quali vengono chiamate segment. Ogni segmento viene scritto sempre sequenzialmente dall inizio alla fine e ogni dato deve essere copiato su un segmento prima di essere riscritto. Allo stesso tempo il log viene salvato (threaded) attraverso la tecnica del

11 CAPITOLO 2. FILE SYSTEM 9 Figura 2.1: Tecniche threading e copying segment-by-segment; se il sistema può allocare una grande quantità di dati in dei segmenti, questi non vengono ricopiati ripetutamente, ma saltati. La dimensione di un segmento viene scelta sufficientemente grande in modo tale che il tempo di scrittura e lettura sia più grande del costo di uno spostamento della testina su un altro segmento. In questo modo si permette di eseguire operazioni sui segmenti utilizzando quasi tutta la larghezza di banda del disco, indipendentemente dall ordine in cui i segmenti sono processati. Segment Cleaning Per Segment Cleaning si intende il meccanismo di copia dei dati al di fuori di un segmento e può essere riassunto in tre step: lettura del numero di segmenti in memoria, identificare i dati e scrivere i dati nuovamente in un numero minore di segmenti puliti. Dopo questa operazioni, i segmenti da cui sono stati letti i dati vengono marcati come clean e possono essere utilizzati per nuovi dati o per cleaning addizionali. Nel processo di Segment Cleaning deve essere possibile identificare quali blocchi di ciascun segmento sono attivi, in modo tale da poterli scrivere nuovamente. Deve essere possibile identificare il file a cui appartiene ciascun blocco e la posizione del blocco all interno del file. Queste informazioni sono necessarie per poter aggiornare l i-node del file che punta alla nuova posizione del blocco quando si effettua la copia. Per risolvere questo problema si fa uso del segment summary block, che viene scritto in una parte di ogni segmento e tiene nota di ogni informazione che è stata scritta in un segmento. I segmenti possono contenere più summary block quando più di una operazioni di log write è necessaria per riempire il segmento. Le informazioni contenute nel summary vengono utilizzate anche per distinguere i blocchi attivi da quelli che sono stati sovrascritti o cancellati. Una volta che si conosce l identità di un blocco, possiamo determinare se questo è attivo

12 CAPITOLO 2. FILE SYSTEM 10 andando a controllare l i-node del file per vedere se il puntatore al blocco fa ancora riferimento a questo blocco. Se questo accade, allora il blocco è attivo, se così non fosse, allora il blocco è inattivo. Questo controllo viene ottimizzato mantenendo un version number, come voce dell i-node map per ogni file, che viene incrementato ogni qual volta il file viene eliminato o troncato a lunghezza zero. Il version number viene combinato con l i-node number per formare un identificatore unico (UID) per il contenuto del file. Il segment summary block salva l UID per ogni blocco presente in un segmento; se l UID di un blocco non combacia con l UID correntemente salvato nell inode map quando il segmento è pulito, il blocco più essere immediatamente scartato senza esaminare l i-node del file. Con questo approccio non vi è bisogno di salvare una free-block list o una bitmap e questo comporta un risparmio di spazio e memoria sul disco, oltre a semplificare le operazioni per il recovery da un crash. Segment Cleaning Policies Dopo aver illustrato il meccanismo di segment cleaning, bisogna focalizzare la nostra attenzione su quattro aspetti decisionali: 1. Quando si dovrebbe eseguire il segment cleaner 2. Quanti segmenti dovrebbero essere puliti in un dato intervallo di tempo 3. Quali segmenti dovrebbero essere puliti 4. Come sistemare poi i dati su disco LSF esegue il segment cleaning quando il numero dei segmenti puliti scende al di sotto di una determinata soglia, di solito poche decine di segmenti. Il cleaning viene effettuato finché il numero di segmenti puliti non supera un altro valore soglia, tipicamente segmenti puliti. In ogni caso non è il valore soglia ad essere influente a livello di prestazioni. Al contrario, la terza e quarta policy sono determinanti nelle performance di un Log-Structured File System. Per poter confrontare queste quattro cleaning policies, introduciamo il termine write cost. Questo è una media del tempo in cui il disco è occupato per scrivere nuovi byte di dati, incluso tutti i cleaning overheads. Il write cost è espresso come il multiplo del tempo che sarebbe richiesto se non ci fossero cleaning overheads e i dati fossero scritti potendo utilizzare tutta la larghezza di banda, senza tempi di ricerca o latenza di rotazione del disco.

13 CAPITOLO 2. FILE SYSTEM 11 Figura 2.2: Write Cost Formula Un write cost pari a 1.0 è perfetto: significherebbe che i nuovi dati potrebbero essere scritti utilizzando tutta la larghezza di banda del disco e non si avrebbe cleaning overhead. Un write cost pari a 10 significa che solo un decimo della massima larghezza di banda del disco viene utilizzato per scrivere i nuovi dati, il resto del tempo viene speso in seek, latenza di rotazione e cleaning. Per un Log-Structured File System con segment di taglia grandi il seek e la latenza di rotazione sono trascurabili sia per la scrittura che per la pulizia, quindi li costo di scrittura è rappresentato dal numero totale di byte spostati da e verso il disco diviso per il numero di byte dei nuovi dati da scrivere. Questo costo è determinato dall utilizzo dei segmenti che sono stati puliti. In uno stato stazionario, il cleaner deve generare un segmento pulito per ogni segmento di nuovi dati che vengono scritti. Quindi vi sono N segmenti da pulire, N u dati all interno degli stessi che producono N (1 u) segment di spazio libero contiguo, con 0 u < 1, come mostrato in figura 5.2. Per recuperare spazio da un segmento parzialmente utilizzato, è necessaria la sua intera lettura. Un blocco vuoto non necessita di essere letto. Un write cost pari a 1.0, indica la possibilità di effettuare una write senza alcun overhead. Possiamo rappresentare il write cost come una funzione di u, come mostrato in figura 5.3. C è da premettere che Unix FFS utilizza il 5-10% della larghezza di banda per i file di piccole dimensioni, per un write cost pari a Con il logging, delayed writes e disk request sorting, questo valore può essere migliorato fino ad arrivare ad un 25% della banda o ad un write cost di 4. La figura 5.2 indica che i segmenti puliti devono essere utilizzati meno di 0.8 per un Log-Structured File System per consentire prestazioni migliori rispetto a Unix FFS. L utilizzo deve essere inferiore a 0.5 per migliorare le prestazioni rispetto all improved FFS. Le prestazioni di Log-Structured File System possono essere migliorate riducendo l utilizzo complessivo dello spazio sul disco. Utilizzando meno disco possibile, i segmenti posti sotto cleaning avranno meno blocchi attivi e come risultato si avrà un basso write cost. LFS fornisce un trade-off costo-prestazioni: se il disco è sottoutilizzato, si avranno prestazioni elevate ma ad un alto costo per ogni byte utilizzabile, se l utilizzo

14 CAPITOLO 2. FILE SYSTEM 12 Figura 2.3: Write cost come funzione di u per small file del disco aumenta, le prestazioni diminuiscono. La chiave per ottenere alte prestazioni a basso costo è quella di ottenere una distribuzione binomiale dei segmenti, dove la maggior parte dei segmenti sono quasi pieni e solo alcuni sono vuoti o quasi vuoti e il cleaner può lavorare quasi sempre su segmenti vuoti. In questo modo si consente un utilizzo performante della capacità del disco, riuscendo ad offrire un write cost basso. Segment Usage Table Per soddisfare le cost-benefit cleaning policy, LFS utilizza una struttura dati chiamata segment usage table. Per ogni segmento, la tabella salva il numero dei byte attivi nel segmento, insieme al tempo di ultima modifica del segmento. Questi due valori sono utilizzati dal segment cleaner quando un segmento per scegliere un segmento da pulire. I valori vengono inizializzati quando il segmento viene scritto e il contatore dei byte attivi viene decrementato quando i file vengono cancellati o dei blocchi vengono riscritti. Se il contatore arriva a zero, allora il segmento può essere riutilizzato senza dover essere pulito. I blocchi della segment usage table sono scritti nel log e gli indirizzi di questi blocchi sono salvati nella checkpoint region. Per permettere un ordinamento dei blocchi in base all età, il segment summary information salva la data di ultima modifica del segmento.

15 CAPITOLO 2. FILE SYSTEM 13 Crash Recovery Quando un sistema va in crash, le ultime operazioni effettuate sul disco potrebbero essere in uno stato inconsistente; durante il riavvio, il sistema operativo cerca di rivedere queste operazioni per ristabilire lo stato di consistenza. In un file system Unix tradizionale senza log, il sistema non può determinare dove l ultimo cambiamento è stato effettuato, quindi è costretto ad effettuare la scansione di tutti le strutture dei metadati sul disco. Il costo di queste operazioni è molto alto e cresce all aumentare delle capacità dei dischi. In un file system Log-Structured l ultima operazione effettuata prima del crash è riportata in fondo al log. LFS utilizza due approcci per effettuare il recovery: checkpoint, che definisce il file system nello stato di consistenza e il roll-forward, che viene utilizzato per recuperare informazioni scritte dopo l ultimo checkpoint. I Checkpoint Un checkpoint è la posizione nel log in cui tutte le strutture del file system sono consistenti e complete. Questo viene creato in due fasi. Nella prima fase annota tutte le informazioni modificate nel log, incluso file data block, indirect block, i-node, i blocchi dell inode map e la segment usage table. Nella seconda fase, si occupa di scrivere la checkpoint region in una fissata e speciale posizione sul disco. La checkpoint region contiene gli indirizzi di tutti i blocchi presenti nell i-node map e la segment usage table, oltre alla data corrente e al puntatore all ultimo segment scritto. Durante il riavvio, LFS legge la checkpoint region e usa le informazioni in essa contenute per inizializzare le proprie strutture dati nella memoria centrale. Dato che potrebbe esserci un crash anche durante le operazioni di checkpoint, è stata introdotta una seconda checkpoint region e le operazioni di checkpoint si alternano tra queste due regioni. Il checkpoint time, che è presente nell ultimo blocco della checkpoint region, fa da discriminante tra le due regioni in quanto non viene aggiornato se l operazione di checkpoint non viene completata. Durante il riavvio, il sistema leggerà le informazioni dalla checkpoint region con il checkpoint time più recente. LFS effettua la scrittura dei checkpoint ad intervalli di tempo periodici o quando il file system non è montato, oppure prima dello spegnimento del sistema. Un lungo intervallo di tempo tra due checkpoint riduce l overhead causato dalla scrittura, ma incrementa il tempo per effettuare il roll-forward durante il recovery; un piccolo intervallo di tem-

16 CAPITOLO 2. FILE SYSTEM 14 po tra due checkpoint incrementa l overhead, ma riduce il tempo di recovery. Un alternativa al checkpointing periodico è quella di effettuare il checkpoint solo quando dei nuovi dati sono stati scritti sul log; questo stabilisce un limite per il tempo di recovery mentre riduce l overhead quando il file system non sta operando al massimo throughput. Roll-Forward Dopo un crash, inizialmente, veniva letta l ultima checkpoint region e veniva scartato ogni dato nel log successivo al checkpoint. Questo modus operandi dava come risultato un recovery istantaneo, ma ogni dato scritto dopo l ultima operazione di checkpoint veniva inevitabilmente perso. Al fine di recuperare quante più informazioni è possibile, LFS effettua una scansione del segmento di log che è stato scritto dopo l ultimo checkpoint e chiama questa operazione: roll-forward. Durante il roll-forward LFS utilizza informazioni residenti nei blocchi del segment summary block per recuperare i dati dei file scritti di recente. Quando un blocco del segment summary block indica la presenza di un nuovo i-node, LFS aggiorna l i-node map letta dal checkpoint in modo tale che possa riferirsi alla nuova copia dell i-node. In questo modo i nuovi data block del file vengono automaticamente accorpati nel file system recuperato. Se i blocchi dei dati vengono scoperti per un file senza che vi sia la presenza di una nuova copia dell i-node del file, il roll-forward assume che la nuova versione del file sul disco è incompleta e ignora i nuovi blocchi di dati appena trovati. Il roll-forward ha il compito di aggiornare il numero di utilizzi nella segment usage table letti dal checkpoint. Gli utilizzi dei segmenti scritti dall ultimo checkpoint avranno valore pari a zero; questo valore deve essere corretto per riflettere i dati attivi introdotti dopo il roll-forward. Gli utilizzi dei vecchi segmenti dovranno essere corretti per essere consistenti con le cancellazioni e le riscritture dei file. Il problema finale che deve risolvere roll-forward riguarda il come ristabilire la consistenza tra directory entry e gli i-node. Ogni i-node contiene un contatore del numero di directory che si riferiscono all i-node stesso e quando questo si azzera, il file viene eliminato. C è da considerare il caso in cui un crash può avvenire quando un i-node è stato scritto nel log con un nuovo contatore, mentre il blocco contenente la entry della corrispondente directory non è stato ancora scritto (o viceversa). Per ripristinare la consistenza tra directory e i-node, LFS inserisce nel log un record speciale chiamato directory operation log. Questo campo include un operation code, che definisce il tipo di operazione che si sta ef-

17 CAPITOLO 2. FILE SYSTEM 15 fettuando, la location della directory entry, i contenuti della directory entry e il nuovo contatore delle referenze per l i-node. LFS garantisce che ogni directory operation log entry appare nel log subito dopo del corrispondente directory block o i-node. Durante il roll-forward, il directory operation log viene utilizzato per gestire la consistenza tra directory entry e i-node: se una entry appare nel log, ma l i-node e il directory block non sono stati scritti, il roll-forward aggiorna la directory e/o l i-node per completare l operazione. Il roll-forward può provocare aggiunta o rimozione di entry, quindi il contatore dell i-node deve essere aggiornato di volta in volta. Il programma di recovery aggiorna le directory modificate, gli i-node, l i-node map e la segment usage table nel log e scrive una nuova regione nel checkpoint con queste informazioni. L unica operazione che non può essere recuperata è la creazione di un nuovo file per cui l i-node non è mai stato scritto. Considerazioni finali Il principio di Log-Structured File System è semplice: raccogliere una gran quantità di dati nuovi in una cache presente nella memoria principale, per poi scrivere i dati sul disco in un unica operazione di I/O, in grado di utilizzare la maggior larghezza di banda possibile del disco. Inizialmente si pensava che, dato l aumento costante delle memorie cache, questa strada poteva essere quella più giusta da percorrere. Con l avvento dei dischi a stato solido, lo spostamento delle testine e il relativo overhead, non rappresenta più un collo di bottiglia per il sistema operativo. Grazie ai tempi di seek trascurabili di queste memorie, l idea dei Log-Structured File System è tornata in auge, poiché questo tipo di memorie permettono un numero limitato di scritture e riscritture dei vari blocchi, Log-Structured File System aumenta la durata di queste memorie grazie al caching ed alle poche, contigue, scritture effettuate sul disco [10].

18 Capitolo 3 Distributed File System 3.1 Introduzione Un sistema di macchine connesse tramite una rete può condividere file fisicamente sparsi su tutta la rete tramite un file system distribuito. Definendo: servizio: programma in esecuzione su una o più macchine, capace di fornire una serie di funzioni a dei client di cui non ha traccia a priori server: programma di servizio in esecuzione su una singola macchina client : programma che può richiedere un servizio tramite una serie di operazioni che costituiscono la sua interfaccia, detta interfaccia client. Un Distributed File System (DFS) è un un file system che fornisce servizi ai suoi client. Un interfaccia per servizi relativi a file è composta da una serie di operazioni primitive sui file (creazione, accesso in lettura e scrittura, cancellazione...). Un DFS è un file system i cui client, server e dispositivi di storage sono sparsi tra le macchine di un sistema distribuito. Il servizio viene eseguito tramite la rete avendo più dispositivi di memorizzazione indipendenti. Le configurazioni e le realizzazioni di un DFS possono essere svariate. Un file system distribuito si può realizzare come parte di un sistema operativo distribuito, oppure con uno strato di programmi che consente la gestione della comunicazione tra sistemi operativi convenzionali ed i file system. 16

19 CAPITOLO 3. DISTRIBUTED FILE SYSTEM Caratteristiche Le caratteristiche che distinguono un file system sono la molteplicità e l autonomia dei client e dei server del sistema. Un DFS deve apparire come un file system centralizzato convenzionale. La molteplicità dei suoi server e dispositivi di storage deve essere trasparente, cioè non deve esistere differenza tra file locale e remoto. Spetta al DFS localizzare e trasportare i dati. Un DFS trasparente facilita la mobilità dell utente portando la propria directory iniziale ovunque esso apra una sessione. Quindi un DFS gestisce un insieme di dispositivi di storage sparsi. Una unità componente è il più piccolo insieme di file che si può memorizzare su una macchina. Tutti che risiedono in una tale unità devo necessariamente essere nella stessa locazione. 3.2 Naming e trasparenza Il naming è una funzione di associazione tra oggetti logici e fisici. Generalmente un utente fa riferimento ad un file tramite il nome testuale, al quale si fa corrispondere un identificare numerico di livello inferiore che a sua volta corrisponde al blocco del disco (trasparenza). Un DFS per garantire la trasparenza, deve necessariamente nascondere la posizione nella rete. In un file system convenzionale un valore della funzione di naming è un indirizzo in un disco. E necessario per tale tipo di file system tenere traccia della specifica macchina che contiene il file. Astraendo il concetto di file è possibile anche replicare un file, dato il nome del file, il sistema riporta una serie di locazioni delle repliche di questo file. In questa astrazione sono nascoste sia l esistenza di copie multiple, sia le locazioni. Riguardo il sistema di associazioni di nomi di un DFS bisogna fornire: 1. Trasparenza di locazione: Il nome non dà informazioni sulla locazione del file 2. Indipendenza della locazione: Non si deve modificare il nome del file se si cambia la locazione nella memoria fisica. La maggior parte dei DFS offre un associazione statica con trasparenza di locazione per i nomi a livello utente. Tuttavia per molti DFS è impossibile cambiare la locazione del file, quindi l indipendenza di locazione è irrilevante. Di solito la mobilità è gestita da un protocollo per soddisfare le richieste degli

20 CAPITOLO 3. DISTRIBUTED FILE SYSTEM 18 utenti senza modificare mai i nomi a livello utente o i nomi a basso livello dei file. Schemi di Naming Tre sono i principali metodi di naming: 1. combinazione nome.macchina e nome.locale per garantire l unicità su tutto il sistema.( Ibis [1] fa tale cosa e nome-locale indica un percorso Unix). Questo schema non gode né di trasparenza di locazione né di indipendenza di locazione. 2. questo metodo si è diffuso con NFS di Sun. Esso offre mezzi per unire le directory remote e quelle locali dando l impressione di un albero di directory coerente. Nelle prime versioni si accedeva a directory remote solo se erano state prima montate. Con l avvento della funzione che fa l auto-mount, i mount vengono eseguiti su richiesta secondo una tabella di punti di montaggio e nomi di strutture file. I componenti sono integrati per gestire la condivisione trasparente, tale integrazione è limitata e non uniforme, perché in questo modo ogni macchina può aggiungere diverse directory remote al proprio albero. Abbiamo trasparenza di allocazione, non indipendenza di allocazione con una struttura molto incostante 3. Abbiamo l integrazione totale dei componenti il DFS è visto come un file system convenzionale. Alcuni file speciali come gli eseguibili su una data macchina rendono difficoltoso tale scopo. 3.3 Accesso ai file remoti Un utente può richiedere l accesso ad un remoto. Una volta che il server che contiene il file è stato localizzato dallo schema di naming, per soddisfare la richiesta si devono trasferire i dati. Il trasferimento è ottenuto tramite il meccanismo di servizio remoto, in cui le richieste sono inviate al server che esegue gli accessi e trasferisce i dati. Un metodo molto usato è quello delle RPC(Remote Procedure Call). Al fine di garantire delle prestazioni ragionevoli si usano delle cache, che nel file system normale consentono una diminuzione degli accessi al disco. Grazie al DFS diminuisce il traffico nella rete e gli accessi ai dischi.

21 CAPITOLO 3. DISTRIBUTED FILE SYSTEM Uso della cache Se i dati necessari alla richiesta non sono stati ancora copiati nella cache si trasferisce una copia di questi dal server al client. Gli accessi sono eseguiti sulla memoria cache, tenendo in essa blocchi di disco a cui si è fatto riferimento di recente per ridurre il traffico. Memorizzazione dati: Disco vs Memoria Centrale La memorizzazione su disco è più affidabile. Se la cache è nella memoria volatile, in caso di crollo del sistema i dati in essa andrebbero persi. Nel caso della cache mantenuta in memoria secondaria, i dati rimangono al suo interno anche dopo il ripristino e non è necessario prelevarli una nuova volta. Le cache in memoria centrale hanno anche vantaggi: uso di stazioni prive di dischi accesso più rapido ai dati rispetto alle cache su disco grazie all avanzare della tecnologia, col passare del tempo le memorie diventano sempre più grandi e quindi meno costose le cache dei server usate per accellerare l I0 dei dischi si trovano in memoria centrale, a prescindere da dove sono posizionate quelle sul client. Quindi, se si usano le cache allo stesso modo anche nelle macchine utenti, si può utilizzare un unico meccanismo di gestione, utilizzabile sia dai server che dai client. Aggiornamento della cache Il criterio che si usa per riscrivere blocchi di dati modificati nella copia principale del server ha un effetto critico sulle prestazioni e sull affidabilità del sistema. Il criterio più semplice è quello di scrivere direttamente i dati nei dischi, appena questi subiscono delle modifiche in una cache qualsiasi. Il vantaggio della scrittura diretta è l affidabilità. Questo criterio richiede che ogni accesso per scrittura attenda l invio delle informazioni al server, ciò implica scarse prestazioni in scrittura. La scrittura differita consiste nel differire gli aggiornamenti nella copia principale. Le modifiche si scrivono nella cache e successivamente nel server. Ha due vantaggi: scritture dirette sulle cache, che consentono di conseguenza accessi in scrittura sono molto più rapidi

22 CAPITOLO 3. DISTRIBUTED FILE SYSTEM 20 si possono sovrascrivere i file prima che siano riportati al server, quindi è necessario riportare solo l ultimo aggiornamento. Tali schemi però causano problemi di affidabilità, in quanto se una macchina subisce un guasto i dati saranno persi perché non ancora scritti nella copia principale del file sul server. 3.4 Servizio Statefull e Servizio Stateless Il server tiene traccia di tutti i file cui ha accesso ogni client, oppure si limita a fornire blocchi secondo quello che richiede il client. Servizio Statefull Prima di accedere ad un file, un client deve eseguire una open. Il server preleva dai suoi dischi informazioni sul file, li registra nella propria memoria e fornisce al client un identificatore di connessione univoco rispetto a quel client e al corrispettivo file aperto. Nei sistemi Unix accade che il server preleva l i-node e fornisce un descrittore del file che viene usato come indice della tabella di i-node presente nella memoria centrale; questo identificatore è utile per gli accessi successivi fino alla fine della sessione. Un servizio con informazioni di stato è caratterizzato da una connessione tra il client ed il server durante una sessione. Quando il file viene chiuso o quando viene attivato un meccanismo di garbage collection, il server può reclamare lo spazio di memoria centrale usato per client che non sono più attivi. Per la tolleranza ai guasti, il server conserva nella memoria centrale le informazioni dei suoi client. Un server senza informazioni di stato evita informazioni di stato ed ogni richiesta è auto-contenuta, cioè ogni richiesta identifica completamente il file e la posizione nel file, per le operazioni di lettura e scrittura. Il server in realtà non dovrebbe avere una tabella di file in memoria ma questo avviene lo stesso per motivi di efficienza. Non sono necessarie operazioni di open e close per aprire e chiudere una connessione, dato che ogni operazione su file è indipendente e non si considera come parte di una sessione. L apertura di un file da parte di un client non causa trasmissione di messaggi remoti. Letture e scritture avvengono come messaggi remoti o come ricerche nella cache. La chiusura finale da parte del client è di nuovo soltanto un operazione locale. Le prestazioni rappresentano il vantaggio tra un informazione di stato rispetto ad un servizio senza informazioni di stato. Le informazioni sul file si copiano in una cache nella memoria centrale ed è possibile accedervi tramite l identificatore di una connessione, risparmiando

23 CAPITOLO 3. DISTRIBUTED FILE SYSTEM 21 sull accesso ai dischi. Se si verifica un crollo durante un attività di servizio. Un server con informazioni di stato perde completamente il proprio stato volatile, che occorre recuperare per assicurare un ripristino conveniente. Ciò avviene tramite un protocollo di ripristino basato su un client. Un recupero meno elegante richiede che tutte le operazioni al momento del crollo vengano annullate. In caso di guasto ad un client, invece, il server deve essere informato, in modo da reclamare spazio per lo stato dei processi client guasti. Tale fenomeno è chiamato rilevamento ed eliminazione degli orfani. Un server senza informazioni di stato non ha nessuno di questi problemi, poiché una volta riparato può rispondere senza difficoltà ad una richiesta auto-contenuta. Dal punto di vista del client non ci sono differenze tra un server lento e un server in via di ripristino: se non riceve una risposta, il client continua a ritrasmettere. Lo svantaggio dell uso del servizio senza informazioni di stato è che messaggi di richiesta sono più lunghi e l elaborazione delle richieste è più lenta, poiché non si dispone di informazioni memorizzate nella memoria centrale capaci di accelerare l elaborazione. Questo servizio impone altri vincoli nella progettazione del DFS. Dato che ogni richiesta identifica il file di destinazione, è necessario l uso di uno schema di naming uniforme e basso livello su tutto il sistema. La traduzione nome remoto-nome locale per ogni richiesta rallenta anche l elaborazione delle richieste. Poiché i client ritrasmettono richieste per operazioni su file, tali operazioni devono essere sempre idempotenti; ciò significa che ogni operazione se si esegue più volte consecutivamente deve dare sempre lo stesso risultato. Gli accessi per lettura e scrittura auto-contenuti sono idempotenti finché adoperano un contatore assoluto che contiene la posizione di accesso all interno del file e non fanno affidamento su uno scostamento incrementale, come con le chiamate read e write in UNIX. Occorre anche avere cura delle operazioni di cancellazione di un file, per rendere anch esse idempotenti. Ci sono ambienti in cui servizi con informazioni di stato diventano necessari. Se il server usa un metodo iniziato dal server per validare la cache, non può fornire un servizio senza informazioni di stato, poiché registra quali file sono stati copiati nella cache di quali client. Il modo in cui UNIX si serve dei descrittori di file e degli scostamenti impliciti è con informazioni di stato. I server devono conservare le tabelle che mettono in corrispondenza i descrittori di file con gli i-node, e memorizzare lo scostamento corrente all interno del file. Questo requisito è richiesto perché NFS, che impiega un servizio senza informazioni di stato, non usa descrittori di file e include uno scostamento esplicito per ogni accesso.

24 CAPITOLO 3. DISTRIBUTED FILE SYSTEM Coerenza Una macchina client deve affrontare il problema di decidere se una copia nella cache sia o no coerente con la copia principale(è aggiornata?). Se la macchina client stabilisce che i dati nella sua copia nella cache non sono aggiornati allora deve ottenerne una copia aggiornata. Può accadere in due modi: 1. Verifica iniziata dal client: Il client inizia un controllo di validità mettendosi in comunicazione con il server per controllare se i dati locali siano coerenti con la copia principale. Per quanto riguarda la frequenza del controllo si può fare prima di ogni accesso oppure anche solo al primo accesso ad un file(quando il file viene aperto). 2. Verifica iniziata dal server: Il server registra, per ogni client, i file che copia nella cache e interviene nel caso individui un incoerenza. Una situazione del genere si verifica quando due client copiano un file in una cache in maniera conflittuale. Il server deve essere informato ogni volta che un file viene aperto, e per ogni apertura deve essere indicata la modalità(read o write). 3.6 Replica La replicazione dei file in un DFS rappresenta una ridondanza utile per migliorare la disponibilità; può influenzare positivamente anche le prestazioni, dato che la scelta di una replica vicina per servire una richiesta di accesso riduce il tempo di servizio. In caso di guasto repliche diverse dello stesso file risiedono in macchine indipendenti. In tal modo la disponibilità di una replica non dipenda da nessun altra copia. Quindi devono essere disponibili mezzi per collocare in particolari macchine queste repliche, tutto in maniera trasparente all utente. Si può anche pensare di avvalersi di un offerta di replicazione a livello utente. Il problema principale delle repliche è l aggiornamento. Le repliche per l utente puntano alla stessa entità logica, se viene modificato una di esse, le modifiche dovranno essere apportate anche sulle altre. Si deve trovare un giusto compromesso tra la coerenza e le prestazioni.

25 CAPITOLO 3. DISTRIBUTED FILE SYSTEM Prestazioni DFS Misurare le prestazioni in un DFS significa misurare il tempo necessario a soddisfare una richiesta di un servizio. In un sistema convenzionale tale tempo è dato dall accesso al disco più una piccola quantità di CPU. In un DFS, un accesso remoto risente anche di un ulteriore carico dovuto alla struttura distribuita, cioè il tempo necessario per inviare la richiesta e per ricevere risposta. Per tali ragioni, oltre al trasferimento dell informazione bisogna considerare anche il carico della CPU dovuto all esecuzione del protocollo di comunicazione. Le prestazioni di un DFS, che si possono considerare come un altra misura della sua trasparenza, devono essere quanto più possibili vicine a quella dell utilizzo di un file system convenzionale.

26 Capitolo 4 Esempi di DFS 4.1 Andrew File System Il file system Andrew, o AFS è un file system distribuito sviluppato dalla Carnegie Mellon University, all interno del progetto Andrew. Il nome è stato dato in onore di Andrew Carnegie e Andrew Mellon. Andrew File System è il file system nato per rendere possibile la condivisione delle informazioni tra i client di tale ambiente. AFS ha avuto svariate implementazioni, alcune commerciali come quella di IBM e altre Open Source, come OpenAFS ( Tale file system è ormai disponibile per una ricca varietà di Sistemi Operativi: svariati Unix, Linux, BSD, OSX/Darwin, Windows (2000+). Andrew ha diversi vantaggi rispetto ai tradizionali file system distribuiti, in particolare riguardo alla sicurezza e alla scalabilità. Per quanto riguarda la sicurezza, AFS utilizza Kerberos per eseguire le autenticazioni e implementa liste per il controllo degli accessi alle singole cartelle per utenti e gruppi. In termini di scalabilità, invece, il sistema è stato progettato per comprendere oltre 5000 workstation Generalità Andrew effettua una distinzione tra macchine client e le macchine server dedicate. I server e i client utilizzano uno dei sistemi operativi supportati e sono collegati attraverso la rete. I client sono presentati con uno spazio di nomi di file partizionato: uno spazio di nomi locali e uno spazio di nomi condiviso. 24

27 CAPITOLO 4. ESEMPI DI DFS 25 Figura 4.1: Architettura Andrew File System Server dedicati, chiamati nel loro insieme, Vice, presentano ai client lo spazio dei nomi condivisi in forma di gerarchia di file: tale gerarchia è omogenea e presenta caratteristiche di trasparenza di locazione, ossia nasconde all utente la natura del file, che esso sia remoto o locale. Lo spazio dei nomi locali è il file system root di una stazione di lavoro, dal quale discende anche lo spazio dei nomi condiviso (a partire dal mount-point /afs). L insieme dei server è responsabile della memorizzazione e della gestione dello spazio dei nomi condiviso. Lo spazio dei nomi locale è piccolo, ogni stazione di lavoro ne possiede uno ed ognuno di essi, contiene programmi di sistema fondamentali per un funzionamento autonomo. Sono locali anche file temporanei e i file che il proprietario della stazione non vuole condividere. L architettura di questo file system è mostrata nella figura Operazioni sui file e semantica della consistenza Il principio fondamentale su cui è basata l architettura di Andrew è il caching per intero dei file, effettuato dai server.

28 CAPITOLO 4. ESEMPI DI DFS 26 Il caching a livello del client permette un miglioramento delle prestazioni, limitando l accesso al file system in caso di un crash del server o un sovraccarico della rete. Nell AFS i file vengono mantenuti nella cache su richiesta della singola workstation. Le operazioni di lettura e scrittura vengono eseguite direttamente sulla copia mantenuta nella cache locale. Quando un file che ha subito delle modifiche viene chiuso, la parte modificata viene copiata sul file presente sul server. Di conseguenza, una stazione di lavoro client interagisce con i server Vice soltanto all apertura e alla chiusura di un file; la lettura e la scrittura, invece, non causano alcuna interazione remota. Più precisamente abbiamo che il sistema operativo di ogni stazione intercetta le system call relative all apertura/chiusura di uno o più file e le invia a un processo a livello utente sulla stessa stazione di lavoro. Questo processo, chiamato Venus, sottopone a caching i file provenienti da Vice nel momento della loro apertura e al momento della chiusura salva le copie modificate dei file sui server dai quali provenivano. Le operazioni di lettura e scrittura, invece, vengono eseguite direttamente dal kernel sulla copia nella cache, aggirando Venus. Questa distinzione fondamentale influenza notevolmente le prestazioni e la semantica delle operazioni su file ma le scritture effettuate su un sito non sono immediatamente visibili sugli altri siti. Il caching viene ulteriormente sfruttato per aperture successive del file nella cache. Venus presuppone che gli elementi nella cache siano validi fintantoché non è specificato diversamente; perciò Venus, all apertura di un file, non deve contattare Vice per validare la copia della cache. La consistenza della cache viene mantenuta da un meccanismo denominato callback. Quando un file si trova nella cache di un client il server ne prende nota e nel caso di una modifica, provvederà a notificarla ai client che ne detengono una copia, riducendo drasticamente il numero delle richieste di validazione della cache ricevute dai server. Tale meccanismo funziona come segue: quando un client A sottopone a caching un elemento del file system, il server aggiorna la sua informazione di stato registrando l avvenuto caching. A questo punto il client A possiede una callback su quel file. Prima di permettere ad un altro client B di modificare il precedente file, il server informa il client A. Così facendo, si dice che il server ha rimosso la callback per il client A. Un client può effettuare una open() su un file nella cache, solo se detiene una callback per lo stesso. Se un client chiude un file dopo averlo modificato, tutti gli altri client che stanno effettuando caching su questo file perdono le loro callback: quando questi

29 CAPITOLO 4. ESEMPI DI DFS 27 client riapriranno il file dovranno ricevere dal server la versione aggiornata Spazio dei nomi condiviso Una caratteristica peculiare dell AFS è il volume, un organizzazione gerarchica ad albero dei file e delle cartelle di ordine inferiore. I volumi sono creati dall amministratore e collegati a specifici nomi di percorso in una cella AFS. Una volta che il volume è stato creato, gli utenti del file system possono creare cartelle e file, senza preoccuparsi della locazione fisica dei dati. Un volume può avere una dimensione fissa, in modo da limitare lo spazio a disposizione per l immagazzinamento dei dati. A seconda delle necessità, l amministratore può trasferire un volume su un diverso server o una diversa locazione del disco, rendendo tale procedura trasparente agli utenti. I volumi possono essere duplicati in copie di sola lettura. Quando viene eseguito un accesso a tali copie, i client possono accedere a copie dei file in sola lettura. Inoltre gli utenti non sono coscienti della locazione spaziale della propria copia di sola lettura; l amministratore può creare e spostare tali volumi a secondo le necessità. AFS garantisce che i dati presenti in un volume di sola lettura siano consistenti con quelli del volume modificabile al momento della creazione del volume stesso. Dal punto di vista concettuale, i volumi vengono uniti tra loro per mezzo di un meccanismo simile al meccanismo di mount di UNIX, ma la differenza di granularità è significativa: in UNIX è possibile montare soltanto un intera partizione. Un file o una directory Vice vengono identificati da un handle di basso livello, chiamato fid. Ogni elemento di directory mappa un pathname su di un fid. Un fid è una struttura dati lunga 96 bit, costituita da tre elementi di uguale dimensione ( 32 bit). Figura 4.2: un numero di volume un numero di v-node un identificatore univoco Il primo identifica univocamente un volume, il secondo serve come puntatore alla tabella di inode di un volume, mentre il terzo elemento, permette di riutilizzare i numeri di v-node su tutti i volumi, mantenendo così le strutture più compatte. Cosa molto importante: i fid sono trasparenti alla locazione,

30 CAPITOLO 4. ESEMPI DI DFS 28 Figura 4.2: Struttura di un fid. quindi lo spostamento di file da server a server non invalida il contenuto delle cache Kernel, server e cache manager I processi client sono interfacciati ad un kernel con il solito set di system call. I kernel sono leggermente modificati per individuare i riferimenti ai file Vice e per inviare richieste al processo Venus, costituendo così il cache manager di Andrew. Venus e i processi server accedono ai file direttamente tramite inode, per evitare il costo della risoluzione del pathname. Poiché l interfaccia i-node non è normalmente visibile ai processi, sono state aggiunte nuove system call. Venus è incaricato in realtà di gestire non una, ma due cache differenti: la prima è utilizzata per i dati mentre la seconda per tenere traccia dello stato del sistema. Per contenere la dimensione di dette cache, viene utilizzato un semplice algoritmo LRU (Least Recently Used). Per ciò che concerne il server, esso consiste di un singolo processo multithread, capace quindi di servire in sinergia le molteplici richieste inviate dalle macchine client. La scelta di un singolo processo multithread piuttosto di una soluzione a multiprocesso permette il caching delle strutture dati necessarie per soddisfare le richieste di servizio. Questo è sì un vantaggio in termini prestazionali, ma che purtroppo sacrifica la tolleranza ai guasti, in quanto, se il processo termina prematuramente, il server si blocca Network File System Il Network File System (NFS) è stato sviluppato in origine dalla Sun Microsystems dagli inizi degli anni ottanta. Un Network File System (NFS) consente di montare delle partizioni su un sistema remoto e utilizzarle come se fossero file system locali. Ciò permette all amministratore del sistema di immagazzinare le risorse in una posizione centrale sulla rete, garantendo agli utenti autorizzati la possibilità di accedervi costantemente. All inizio era

31 CAPITOLO 4. ESEMPI DI DFS 29 disponibile solo per sistemi Unix, poi data la sua popolarità è stato sviluppato per la maggior parte delle piattaforme esistenti, tanto da diventare il file system distribuito più diffuso Caratteristiche NFS NFS è stato pensato in maniera tale che ogni nodo funge sia da client e che da server allo stesso tempo. In tal modo è possibile mettere a disposizione parti del proprio file system per altri nodi e allo stesso tempo montare file system ubicati su altro nodo nella rete. Fino a NFSv3 il protocollo è di tipo stateless. Il server non ha informazioni sui file aperti dai client, non ci sono operazioni di apertura e chiusura e le chiamate di apertura, lettura e scrittura del file sono svolte tramite singole chiamate RPC (Remote Procedure Call). Ogni client ha una propria visione dei file globali, la quale dipende solo dai mount fatti. Ogni operazione su file deve passare attraverso il server per la validazione Critiche ad NFS Una delle critiche che può essere fatta ad Network File System è che i server vengono identificati e montati tramite il comando mount, con un azione specifica dell utente oppure pianificata (ad esempio all avvio del sistema). Tale caratteristica si scontra con una delle principali obiettivi di un file system distribuito, cioè fornire trasparenza all utente. Le versioni precedenti alla versione 4 di NFS non facevano uso di veri e propri meccanismi di caching, che come abbiamo visto con AFS migliorano e non di poco le performance di un file system distribuito. Inoltre sempre prima della versione 4, descritta nel prossimo paragrafo, NFS era afflitta da problemi di sicurezza. La maggior parte di questi, riscontrabile specialmente in NFSv2, sfruttava una poca accortezza nell implementazione che permetteva a qualche utente malizioso di poter esportare un determinato file system nel gruppo EveryOne(cioè visibile a tutti gli utenti). La modifica del permesso d accesso aveva come conseguenza il fatto che un utente poteva, da qualsiasi postazione remota, fare il mount del file system in questione e avere libero accesso a tutti i dati memorizzati nelle directory dell albero.

32 CAPITOLO 4. ESEMPI DI DFS 30 NFS versione 4 L ultima versione di NFS è NFSv4, che è differisce di molto dalle versioni precedenti. Il protocollo in questa versione è diventato statefull, il server quindi mantiene lo stato della sessione client dall apertura del file remoto fino alla sua chiusura. Il protocollo NFS mette a disposizione in questa versione le operazioni open() e close()(a differenza delle precedenti versioni stateless). Le versioni precedenti adottavano vari protocolli per il montaggio a distanza e applicavano lock ai file remoti, mentre NFSv4 unifica queste funzionalità in un unico protocollo. In particolare il protocollo mount, falla conosciuta nell implementazione di NFS è stato eliminato, rendendo possibile accoppiare NFS con i firewall. NFSv4 ha migliorato la capacità dei file di copiare localmente i file nella cache. Si tratta di una modifica che aumenta le prestazioni del sistema, perché i client sono in gradi di servire un maggior numero di accessi ai file localmente, senza ricorrere al server. I client possono anche richiedere al server l applicazione di lock ai file remoti: se il server accoglie la richiesta, il client man tiene il lock fino al rilasci o alla scadenza del suo diritto di applicarlo(si può rinnovare tale richiesta concordandola con il server). I sistemi basati su Unix permettono i lock facoltativi, mentre quelli Windows impongono lock obbligatori. La versione 4 mette a disposizione i lock facoltativi, per far funzionare bene NFS anche con sistemi diversi da quelli Unix. Questi nuovi meccanismi di gestione di cache e lock si fondano sul concetto di delaga, in virtù della quale il server delega la responsabilità inerente al lock e ai contenuti di un file; gli altri client presentano le richieste per il lock e l accesso al file al delegato, finché questi non rimuova il lock è rimetta la delega. Delegare tali responsabilità ai client riduce il carico dle server e migliora il grado di coerenza della cache. Mentre le versioni precedenti a NFSv4 si basano su UDP, essa usa TCP, che permette migliori aggiustamenti in presenza di variazioni di traffico nella rete. 4.2 Altri tipi di DFS: SMB, CIFS, SAMBA Di seguito andremo ad elencare, altri tipi di file system distribuiti che sono di uso abbastanza comune nella rete, ovvero Service Message Block, Common Internet File System, Samba.

33 CAPITOLO 4. ESEMPI DI DFS Service Message Block Service Message Block, meglio conosciuto con il suo acronimo come SMB nasce nel 1985, presso IBM come protocollo di supporto a NetBios( Network Basic Input/Output System ) e veniva usato per condividere file e comunicazioni di varia natura tra diversi nodi di una rete. Di fatto NetBios era un interfaccia di programmazione (API) fatta sviluppare da IBM nel 1983 per permettere a delle applicazioni di comunicare scambiandosi file e messaggi sui PC network del tempo, che avevano un basso numero di host e non prevedevano ancora l uso del protocollo IP (già presente ma usato più su WAN che in LAN) per le comunicazioni di rete. SMB è un protocollo di livello applicativo utilizzato per la condivisione di directory fra computer, la stampa via rete e lo scambio di file e messaggi. Si basa su una struttura client-server ed ha una logica di tipo request-response. Dalla sua introduzione originaria ha subito varie modifiche e varianti che modificano e aggiungono nuovi SMB (Server Message Blocks, di fatto i comandi utilizzabili). Si può definire come il progenitore del ben più noto Common Internet File System di Microsoft, il quale riprende l idea di questo protocollo apportando delle migliorie e di conseguenza influenza anche Samba, un implementazione OpenSource del protocollo che è utilizzabile su gran parte degli Unix in circolazione Common Internet File System Common Internet File System o (CIFS) nasce in casa Microsoft nel 1998 come risposta a NFS della Sun. Microsoft utilizza NetBios e SMB come protocolli di rete per condividere risorse su Windows fin dalla versione Windows 3.1. Rispetto alle versioni esistenti di questi protocolli ha introdotto alcune estensioni proprietarie: Domini Windows: Fondamentalmente un dominio Windows è un workgroup con un server che agisce come Domain Controller con funzioni di autenticazione centralizzata per l accesso alle risorse (file, stampanti, login sul sistema, ecc...) da parte tutti gli host che fanno parte del dominio stesso. Vengono usati protocolli differenti per Windows 95/98, Windows NT e Windows 2000 (dove il concetto di dominio viene ulteriormente allargato con le Active Directory). Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password:

34 CAPITOLO 4. ESEMPI DI DFS 32 quando un client cerca di accedere alle risorse di un server, quest ultimo verifica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse in rete accessibili dalla stessa login. Il database delle password viene automaticamente copiato su uno o più Backup Domain Controller (BDC) che possono essere utilizzati per autenticare i client nel caso in cui i PDC sia inaccessibile. Browsing: Per rendere più rapida l individuazione degli host e delle risorse in una rete locale, Microsoft ha introdotto il Local Master Browser un computer che ha il ruolo di mantenere la lista degli host in rete (browse list) e che fa da riferimento per tutte le richieste e gli aggiornamenti da parte delle altre macchine in rete. Praticamente ogni macchina Windows può agire da Local Master Browser o da Backup Browser (host che riceve la browse list da un Master Browser e viene utilizzata in caso di inagibilità di quest ultimo). Queste funzionalità vengono definite automaticamente dagli host NetBios in una rete locale tramite una procedura chiamata elezione in cui tutti gli host partecipano tramite broadcast. A seconda del sistema operativo, della versione di protocollo utilizzata, del tempo di uptime nella rete e del nome dell host viene automaticamente deciso chi deve operare come Master Browser e questo rimane tale fino a quando resta connesso o un nuovo host con migliori credenziali si aggiunge alla rete. Quando si clicca, in Windows, su Risorse di Rete di fatto si ottiene dal Master Browser la browse list degli host in rete (notare che questa potrebbe essere non perfettamente aggiornata, con alcuni host che risultano presenti anche se magari sono spenti o disconnessi e non hanno avuto modo di comunicarlo al Master Browser), quando si clicca sul singolo host si ottiene l elenco delle sue risorse condivise. Server WINS: Il Windows Internet Name Service (WINS) è l implementazione Microsoft di un NetBios Name Server (NBNS) che ha la funzione di mantenere la lista dei nomi NetBios degli host in rete e dei relativi indirizzi IP. Ovviamente questo serve quando si usa NetBios over TCP/IP ed è una soluzione consigliabile quando si ha una rete medio grande o si devono connettere workgroup presenti su network IP differenti. Anche in questo caso, oltre ad un Primary Wins Serv-

35 CAPITOLO 4. ESEMPI DI DFS 33 er possono esistere uno o più Secondary Wins Server con funzioni di ridondanza e backup. Lo svantaggio più grande di questo protocollo è che non fornisce supporto a piattaforme diverse da quelle Microsoft SAMBA Il progetto Samba, come detto in questo capitolo è un implementazione OpenSource(l unica), la quale utilizza il protocollo SMB così come definito in CIFS da parte di Microsoft, che ha come scopo quello di garantisce la compatibilità tra piattaforme anche diverse da quelle dell azienda di Redmond. Il protocollo Samba, è ormai incluso nella maggior parte delle distribuzioni Unix, anche se non sempre viene installato di default, il suo scopo è in effetti, far diventare la nostra macchina Linux, una risorsa visibile e perfettamente sfruttabile, all interno di una rete di computer Windows preesistente. In tal modo le directory del file system appaiono agli utenti Microsoft Windows come delle normali cartelle Windows accessibili via rete. Per quanto riguarda il mount su Unix, questo può essere fatto direttamente sull albero del file system. Informazioni dettagliate sulla sua installazione e configurazioni sono disponibili su [9].

36 Capitolo 5 Log-Structured File System Introduzione Il Log-Structured File System (LFS) nasce nel 1992 con l obiettivo di migliorare le performance dello storage dei dati sui dischi, fornendo un nuovo modello di organizzazione e gestione del disco. Tale necessità nacque dall incremento esponenziale delle performance delle CPU, la cui potenza era cresciuta a tal punto da rendere le operazioni di I/O il collo di bottiglia di un sistema. Uno dei principi su cui si basa LFS è quello di mantenere i file nella memoria centrale; in modo da migliorare le performance della lettura, ed ottimizzare la scrittura dei file sfruttando blocchi contigui di memoria libera. I sistemi sarebbero così non più dominati dalle operazioni di I/O, ma solo da operazioni di scrittura effettiva del disco. Una ottimizzazione della operazione di scrittura avrebbe reso l accesso al disco meno gravoso da parte del sistema operativo. LSF effettua la scrittura delle informazioni sul disco utilizzando una struttura sequenziale chiamata log; in tal modo vengono ottimizzate le operazioni di scrittura, evitando di dover effettuare scansioni dell intero disco per la ricerca di informazioni. La natura sequenziale del log permette anche il recupero dai crash in maniera molto veloce: i normali file system senza meccanismo di log necessitano di una scansione intera del disco per ripristinare la consistenza, ma LFS attraverso l utilizzo del log si limita ad esaminare solo la parte finale del log. 34

37 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM Progettazione Log-Structured File System cerca di aumentare le performance, bufferizzando una sequenza di modifiche del file system in un file e successivamente scrivere questi cambiamenti in maniera sequenziale, in una singola operazione di scrittura. Le informazioni scritte sul disco includono file data block, attributi, index blocks, directory e quasi tutte le altre informazioni utilizzate per gestire il file system. Se il flusso di dati da scrivere è composto da molti piccoli file, LFS converte queste piccole scritture sincrone in un unica grande scrittura asincrona in modo da sfruttare tutta la larghezza di banda del disco. Per apportare effettivi benefici in fase di scrittura. Vi sono due problemi chiave da risolvere: gestire lo spazio libero sul disco e gestire il recupero delle informazioni dal file di log Gestione dello spazio libero La difficoltà principale nella progettazione di LFS è la gestione dello spazio libero. L obiettivo è quello di poter avere a disposizione larghe estensioni di spazio libero per le scritture di nuovi dati. Inizialmente tutto lo spazio libero è rappresentato da una singola estensione sul disco, ma, con il passare del tempo, il log raggiunge la fine del disco e lo spazio libero viene frammentato in tante piccole estensioni corrispondenti ai file che sono stati eliminati o riscritti. A questo punto il file system ha due opzioni: threading o copying. Il threading consiste nel salvare i dati in un luogo sul disco e posizionare il log nelle estensioni restanti. Sfortunatamente il threading causa una fitta frammentazione, inoltre larghe scritture contigue non sono possibili e quindi il Log-Structured File System non risulterebbe più veloce rispetto ai tradizionali file system. La seconda alternativa è quella di copiare i dati al di fuori del log in modo da avere larghe estensioni di spazio libero. Lo svantaggio di questa alternativa consiste nel costo, soprattutto per file longevi. Nel caso più semplice, in cui il log lavora circolarmente sul disco e i dati vengono copiati nel log, tutti i dati già presenti nel log (file longevi) devono essere ricopiati ad ogni aggiornamento del log. In figura 5.1 vengono mostrate le due tecniche. LSF utilizza una combinazione del threading e del copying. Il disco viene diviso in larghe zone con un estensione fissata, le quali vengono chiamate segment. Ogni segmento viene scritto sempre sequenzialmente dall inizio alla fine e ogni dato deve essere copiato su un segmento prima di essere riscritto. Allo stesso tempo il log viene salvato (threaded) attraverso la tecnica del

38 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 36 Figura 5.1: Tecniche threading e copying segment-by-segment; se il sistema può allocare una grande quantità di dati in dei segmenti, questi non vengono ricopiati ripetutamente, ma saltati. La dimensione di un segmento viene scelta sufficientemente grande in modo tale che il tempo di scrittura e lettura sia più grande del costo di uno spostamento della testina su un altro segmento. In questo modo si permette di eseguire operazioni sui segmenti utilizzando quasi tutta la larghezza di banda del disco, indipendentemente dall ordine in cui i segmenti sono processati. Segment Cleaning Per Segment Cleaning si intende il meccanismo di copia dei dati al di fuori di un segmento e può essere riassunto in tre step: lettura del numero di segmenti in memoria, identificare i dati e scrivere i dati nuovamente in un numero minore di segmenti puliti. Dopo questa operazioni, i segmenti da cui sono stati letti i dati vengono marcati come clean e possono essere utilizzati per nuovi dati o per cleaning addizionali. Nel processo di Segment Cleaning deve essere possibile identificare quali blocchi di ciascun segmento sono attivi, in modo tale da poterli scrivere nuovamente. Deve essere possibile identificare il file a cui appartiene ciascun blocco e la posizione del blocco all interno del file. Queste informazioni sono necessarie per poter aggiornare l i-node del file che punta alla nuova posizione del blocco quando si effettua la copia. Per risolvere questo problema si fa uso del segment summary block, che viene scritto in una parte di ogni segmento e tiene nota di ogni informazione che è stata scritta in un segmento. I segmenti possono contenere più summary block quando più di una operazioni di log write è necessaria per riempire il segmento. Le informazioni contenute nel summary vengono utilizzate anche per distinguere i blocchi attivi da quelli che sono stati sovrascritti o cancellati. Una volta che si conosce l identità di un blocco, possiamo determinare se questo è attivo

39 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 37 andando a controllare l i-node del file per vedere se il puntatore al blocco fa ancora riferimento a questo blocco. Se questo accade, allora il blocco è attivo, se così non fosse, allora il blocco è inattivo. Questo controllo viene ottimizzato mantenendo un version number, come voce dell i-node map per ogni file, che viene incrementato ogni qual volta il file viene eliminato o troncato a lunghezza zero. Il version number viene combinato con l i-node number per formare un identificatore unico (UID) per il contenuto del file. Il segment summary block salva l UID per ogni blocco presente in un segmento; se l UID di un blocco non combacia con l UID correntemente salvato nell inode map quando il segmento è pulito, il blocco più essere immediatamente scartato senza esaminare l i-node del file. Con questo approccio non vi è bisogno di salvare una free-block list o una bitmap e questo comporta un risparmio di spazio e memoria sul disco, oltre a semplificare le operazioni per il recovery da un crash. Segment Cleaning Policies Dopo aver illustrato il meccanismo di segment cleaning, bisogna focalizzare la nostra attenzione su quattro aspetti decisionali: 1. Quando si dovrebbe eseguire il segment cleaner 2. Quanti segmenti dovrebbero essere puliti in un dato intervallo di tempo 3. Quali segmenti dovrebbero essere puliti 4. Come sistemare poi i dati su disco LSF esegue il segment cleaning quando il numero dei segmenti puliti scende al di sotto di una determinata soglia, di solito poche decine di segmenti. Il cleaning viene effettuato finché il numero di segmenti puliti non supera un altro valore soglia, tipicamente segmenti puliti. In ogni caso non è il valore soglia ad essere influente a livello di prestazioni. Al contrario, la terza e quarta policy sono determinanti nelle performance di un Log-Structured File System. Per poter confrontare queste quattro cleaning policies, introduciamo il termine write cost. Questo è una media del tempo in cui il disco è occupato per scrivere nuovi byte di dati, incluso tutti i cleaning overheads. Il write cost è espresso come il multiplo del tempo che sarebbe richiesto se non ci fossero cleaning overheads e i dati fossero scritti potendo utilizzare tutta la larghezza di banda, senza tempi di ricerca o latenza di rotazione del disco.

40 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 38 Figura 5.2: Write Cost Formula Un write cost pari a 1.0 è perfetto: significherebbe che i nuovi dati potrebbero essere scritti utilizzando tutta la larghezza di banda del disco e non si avrebbe cleaning overhead. Un write cost pari a 10 significa che solo un decimo della massima larghezza di banda del disco viene utilizzato per scrivere i nuovi dati, il resto del tempo viene speso in seek, latenza di rotazione e cleaning. Per un Log-Structured File System con segment di taglia grandi il seek e la latenza di rotazione sono trascurabili sia per la scrittura che per la pulizia, quindi li costo di scrittura è rappresentato dal numero totale di byte spostati da e verso il disco diviso per il numero di byte dei nuovi dati da scrivere. Questo costo è determinato dall utilizzo dei segmenti che sono stati puliti. In uno stato stazionario, il cleaner deve generare un segmento pulito per ogni segmento di nuovi dati che vengono scritti. Quindi vi sono N segmenti da pulire, N u dati all interno degli stessi che producono N (1 u) segment di spazio libero contiguo, con 0 u < 1, come mostrato in figura 5.2. Per recuperare spazio da un segmento parzialmente utilizzato, è necessaria la sua intera lettura. Un blocco vuoto non necessita di essere letto. Un write cost pari a 1.0, indica la possibilità di effettuare una write senza alcun overhead. Possiamo rappresentare il write cost come una funzione di u, come mostrato in figura 5.3. C è da premettere che Unix FFS utilizza il 5-10% della larghezza di banda per i file di piccole dimensioni, per un write cost pari a Con il logging, delayed writes e disk request sorting, questo valore può essere migliorato fino ad arrivare ad un 25% della banda o ad un write cost di 4. La figura 5.2 indica che i segmenti puliti devono essere utilizzati meno di 0.8 per un Log-Structured File System per consentire prestazioni migliori rispetto a Unix FFS. L utilizzo deve essere inferiore a 0.5 per migliorare le prestazioni rispetto all improved FFS. Le prestazioni di Log-Structured File System possono essere migliorate riducendo l utilizzo complessivo dello spazio sul disco. Utilizzando meno disco possibile, i segmenti posti sotto cleaning avranno meno blocchi attivi e come risultato si avrà un basso write cost. LFS fornisce un trade-off costo-prestazioni: se il disco è sottoutilizzato, si avranno prestazioni elevate ma ad un alto costo per ogni byte utilizzabile, se l utilizzo

41 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 39 Figura 5.3: Write cost come funzione di u per small file del disco aumenta, le prestazioni diminuiscono. La chiave per ottenere alte prestazioni a basso costo è quella di ottenere una distribuzione binomiale dei segmenti, dove la maggior parte dei segmenti sono quasi pieni e solo alcuni sono vuoti o quasi vuoti e il cleaner può lavorare quasi sempre su segmenti vuoti. In questo modo si consente un utilizzo performante della capacità del disco, riuscendo ad offrire un write cost basso. Segment Usage Table Per soddisfare le cost-benefit cleaning policy, LFS utilizza una struttura dati chiamata segment usage table. Per ogni segmento, la tabella salva il numero dei byte attivi nel segmento, insieme al tempo di ultima modifica del segmento. Questi due valori sono utilizzati dal segment cleaner quando un segmento per scegliere un segmento da pulire. I valori vengono inizializzati quando il segmento viene scritto e il contatore dei byte attivi viene decrementato quando i file vengono cancellati o dei blocchi vengono riscritti. Se il contatore arriva a zero, allora il segmento può essere riutilizzato senza dover essere pulito. I blocchi della segment usage table sono scritti nel log e gli indirizzi di questi blocchi sono salvati nella checkpoint region. Per permettere un ordinamento dei blocchi in base all età, il segment summary information salva la data di ultima modifica del segmento.

42 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM Crash Recovery Quando un sistema va in crash, le ultime operazioni effettuate sul disco potrebbero essere in uno stato inconsistente; durante il riavvio, il sistema operativo cerca di rivedere queste operazioni per ristabilire lo stato di consistenza. In un file system Unix tradizionale senza log, il sistema non può determinare dove l ultimo cambiamento è stato effettuato, quindi è costretto ad effettuare la scansione di tutti le strutture dei metadati sul disco. Il costo di queste operazioni è molto alto e cresce all aumentare delle capacità dei dischi. In un file system Log-Structured l ultima operazione effettuata prima del crash è riportata in fondo al log. LFS utilizza due approcci per effettuare il recovery: checkpoint, che definisce il file system nello stato di consistenza e il roll-forward, che viene utilizzato per recuperare informazioni scritte dopo l ultimo checkpoint. Checkpoint Un checkpoint è la posizione nel log in cui tutte le strutture del file system sono consistenti e complete. Questo viene creato in due fasi. Nella prima fase annota tutte le informazioni modificate nel log, incluso file data block, indirect block, i-node, i blocchi dell inode map e la segment usage table. Nella seconda fase, si occupa di scrivere la checkpoint region in una fissata e speciale posizione sul disco. La checkpoint region contiene gli indirizzi di tutti i blocchi presenti nell i-node map e la segment usage table, oltre alla data corrente e al puntatore all ultimo segment scritto. Durante il riavvio, LFS legge la checkpoint region e usa le informazioni in essa contenute per inizializzare le proprie strutture dati nella memoria centrale. Dato che potrebbe esserci un crash anche durante le operazioni di checkpoint, è stata introdotta una seconda checkpoint region e le operazioni di checkpoint si alternano tra queste due regioni. Il checkpoint time, che è presente nell ultimo blocco della checkpoint region, fa da discriminante tra le due regioni in quanto non viene aggiornato se l operazione di checkpoint non viene completata. Durante il riavvio, il sistema leggerà le informazioni dalla checkpoint region con il checkpoint time più recente. LFS effettua la scrittura dei checkpoint ad intervalli di tempo periodici o quando il file system non è montato, oppure prima dello spegnimento del sistema. Un lungo intervallo di tempo tra due checkpoint riduce l overhead causato dalla scrittura, ma incrementa il tempo per effettuare il roll-forward durante il recovery; un piccolo intervallo di tem-

43 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 41 po tra due checkpoint incrementa l overhead, ma riduce il tempo di recovery. Un alternativa al checkpointing periodico è quella di effettuare il checkpoint solo quando dei nuovi dati sono stati scritti sul log; questo stabilisce un limite per il tempo di recovery mentre riduce l overhead quando il file system non sta operando al massimo throughput. Roll-Forward Dopo un crash, inizialmente, veniva letta l ultima checkpoint region e veniva scartato ogni dato nel log successivo al checkpoint. Questo modus operandi dava come risultato un recovery istantaneo, ma ogni dato scritto dopo l ultima operazione di checkpoint veniva inevitabilmente perso. Al fine di recuperare quante più informazioni è possibile, LFS effettua una scansione del segmento di log che è stato scritto dopo l ultimo checkpoint e chiama questa operazione: roll-forward. Durante il roll-forward LFS utilizza informazioni residenti nei blocchi del segment summary block per recuperare i dati dei file scritti di recente. Quando un blocco del segment summary block indica la presenza di un nuovo i-node, LFS aggiorna l i-node map letta dal checkpoint in modo tale che possa riferirsi alla nuova copia dell i-node. In questo modo i nuovi data block del file vengono automaticamente accorpati nel file system recuperato. Se i blocchi dei dati vengono scoperti per un file senza che vi sia la presenza di una nuova copia dell i-node del file, il roll-forward assume che la nuova versione del file sul disco è incompleta e ignora i nuovi blocchi di dati appena trovati. Il roll-forward ha il compito di aggiornare il numero di utilizzi nella segment usage table letti dal checkpoint. Gli utilizzi dei segmenti scritti dall ultimo checkpoint avranno valore pari a zero; questo valore deve essere corretto per riflettere i dati attivi introdotti dopo il roll-forward. Gli utilizzi dei vecchi segmenti dovranno essere corretti per essere consistenti con le cancellazioni e le riscritture dei file. Il problema finale che deve risolvere roll-forward riguarda il come ristabilire la consistenza tra directory entry e gli i-node. Ogni i-node contiene un contatore del numero di directory che si riferiscono all i-node stesso e quando questo si azzera, il file viene eliminato. C è da considerare il caso in cui un crash può avvenire quando un i-node è stato scritto nel log con un nuovo contatore, mentre il blocco contenente la entry della corrispondente directory non è stato ancora scritto (o viceversa). Per ripristinare la consistenza tra directory e i-node, LFS inserisce nel log un record speciale chiamato directory operation log. Questo campo include un operation code, che definisce il tipo di operazione che si sta ef-

44 CAPITOLO 5. LOG-STRUCTURED FILE SYSTEM 42 fettuando, la location della directory entry, i contenuti della directory entry e il nuovo contatore delle referenze per l i-node. LFS garantisce che ogni directory operation log entry appare nel log subito dopo del corrispondente directory block o i-node. Durante il roll-forward, il directory operation log viene utilizzato per gestire la consistenza tra directory entry e i-node: se una entry appare nel log, ma l i-node e il directory block non sono stati scritti, il roll-forward aggiorna la directory e/o l i-node per completare l operazione. Il roll-forward può provocare aggiunta o rimozione di entry, quindi il contatore dell i-node deve essere aggiornato di volta in volta. Il programma di recovery aggiorna le directory modificate, gli i-node, l i-node map e la segment usage table nel log e scrive una nuova regione nel checkpoint con queste informazioni. L unica operazione che non può essere recuperata è la creazione di un nuovo file per cui l i-node non è mai stato scritto Considerazioni finali Il principio di Log-Structured File System è semplice: raccogliere una gran quantità di dati nuovi in una cache presente nella memoria principale, per poi scrivere i dati sul disco in un unica operazione di I/O, in grado di utilizzare la maggior larghezza di banda possibile del disco. Inizialmente si pensava che, dato l aumento costante delle memorie cache, questa strada poteva essere quella più giusta da percorrere. Con l avvento dei dischi a stato solido, lo spostamento delle testine e il relativo overhead, non rappresenta più un collo di bottiglia per il sistema operativo. Grazie ai tempi di seek trascurabili di queste memorie, l idea dei Log-Structured File System è tornata in auge, poiché questo tipo di memorie permettono un numero limitato di scritture e riscritture dei vari blocchi, Log-Structured File System aumenta la durata di queste memorie grazie al caching ed alle poche, contigue, scritture effettuate sul disco [10].

45 Capitolo 6 Software per il benchmarking di file system Le misure delle prestazioni di un sistema informatico si effettuano eseguendo i cosiddetti benchmark: software appositi, che misurano determinati parametri del sistema, in varie condizioni di lavoro. Nello specifico, i benchmark che ci interessano sono quelli che performano operazioni di Input/Output (I/O) sul disco. Questo tipo di benchmark consiste in programmi che eseguono delle operazioni di scrittura e lettura in varie condizioni, cambiando la dimensione del file, la lunghezza del record, il tipo di accesso e così via. Nell effettuare tali benchmark di I/O, bisogna fare molta attenzione ad alcuni valori che incidono molto sul risultato finale, tipicamente questi valori si misurano in Kbyte/sec. Questo perché le operazioni vengono eseguite da un programma che gira su di un determinato sistema, sotto le condizioni di quest ultimo e su determinate specifiche hardware. Tutte queste caratteristiche devono essere studiate con attenzione, ai fini di una buona interpretazione dei dati ottenuti. Infatti, va considerato che alle prestazioni complessive contribuiscono vari fattori, tra cui i principali sono: dimensione della cache della CPU dimensione della cache di I/O del sistema operativo dimensione della cache del controller di accesso dimensione della cache del disco 43

46 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM44 Facciamo qualche esempio: oggi la cache L2 della CPU, una memoria molto veloce presente direttamente sul chip, è di almeno 2 Mbyte fino a raggiungere un massimo di 4 Mbyte: se facessimo operazioni di scrittura e di lettura su un file di 1 Mbyte, su un sistema dedicato (quindi senza avere ulteriori utenti connessi), molto probabilmente le operazioni di lettura prenderanno i dati direttamente dalla cache L2, ottenendo così, in termini di prestazioni, tempistiche decisamente ridotte, cosa che molto probabilmente non riusciremo ad avere, con file aventi taglia superiore a quella della cache L2. Lo stesso concetto va applicato a tutte le altre cache citate sopra. In questo capitolo vengono presentati i benchmark per file system più noti IOzone IOzone è software di benchmarking per file system, che genera e misura una moltitudine di operazioni. Il porting di IOzone è stato effettuato per molte architetture e sistemi operativi. IOzone è utile per eseguire un ampia analisi del file system su sistemi informatici. I test delle prestazioni di lettura e scrittura disponibili si dividono in due sotto categorie: sequenziale e random [4]. L output ottenuto da tale software è di tipo testuale in forma tabellare, come è possibile vedere in figura 6.1. Test di scrittura e lettura sequenziale Write: questo test misura le prestazioni di scrittura di un nuovo file. Ciò vuole dire non solo la scrittura dei dati, ma anche delle informazioni sulla posizione del file, sulla sua dimensione e sugli altri parametri del file system, cioè i così detti metadati. L operazione di write è chiaramente più lenta rispetto alla seguente operazione di re-write dello stesso file Re-Write: questo test misura le prestazioni nella scrittura di un file già esistente. Questo vuol dire che i metadati non vengono riscritti, o che solo pochi di essi lo sono. Chiaramente l operazione è più veloce della precedente Read: questo test misura le prestazioni nella lettura di un file già esistente

47 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM45 Re-Read: questo test misura le prestazioni nella lettura di un file già esistente che è già stato letto di recente. Poiché il sistema operativo bufferizza in cache i dati letti, le prestazioni riportate da questo test sono generalmente migliori delle precedenti Backwards Read: questo test misura le prestazioni nella lettura di un file letto dalla fine verso l inizio. Seppur bizzarro, il test è utile dato che vi sono diverse applicazioni che leggono i file al contrario. Un esempio è NASTRAN un programma della NASA per il calcolo approssimato di equazioni differenziali parziali Fwrite: questo test misura le prestazioni di scrittura di un file con la funzione di libreria fwrite(), la quale utilizza un buffer nello spazio di indirizzamento del programma utente. Sono scritti anche i metadati. Frewrite: Come il precedente, ma senza metadati o con l aggiornamento di alcuni. Fread: questo test misura le prestazioni della lettura di un file con la funzione di libreria fread(), la quale utilizza un buffer nello spazio di indirizzamento del programma utente. Freread: come il precedente, ma con la possibilità di avere i dati nella cache del sistema operativo. Test di scrittura e lettura random Random Read: questo test misura le prestazioni della lettura di parti random di un file. Le prestazioni dipendono da numerosi fattori, come la dimensione della cache, il numero di dischi, i relativi tempi di latenza ecc. Random Write: questo test misura le prestazioni della scrittura di punti random di un file. Le prestazioni dipendono, come per il test precedente, da numerosi fattori, come la dimensione della cache, il numero dei dischi, i relativi tempi di latenza ecc. Random Mix: questo test misura le prestazioni nella lettura e nella scrittura di un file non dall inizio alla fine, ma in punti random del file stesso. Le prestazioni dipendono da numerosi fattori, come la dimensione della cache, il numero di dischi, i relativi tempi di latenza ecc.

48 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM46 Il test va eseguito con più processi che eseguono simultaneamente lo stesso test, alternativamente, cioè un test scrive, il successivo legge e così via. Si tratta quindi di uno stress test. Strided Read: questo test misura le prestazioni di lettura di un file in modo così detto strided, cioè una prima lettura, ad esempio di 4kbyte, poi un salto, ad esempio di 200Kbyte, poi di nuovo ciclicamente una lettura ed un salto. In genere, i sistemi operativi non ottimizzano affatto questa funzione. Record Rewrite: questo test misura le prestazioni nella scrittura di una porzione (un record) del file in un suo punto intermedio e poi nella riscrittura della stessa porzione. Se il record è piccolo ed entra nella cache della CPU, le prestazioni sono alte; se il record non entra nella cache della CPU, ma nella TLB ( Translation Lookaside Buffer, ovvero un buffer o nelle implementazioni più sofisticate rappresenta una cache), ossia una struttura dati che traduce gli indirizzi di memoria virtuali in indirizzi reali, le prestazioni sono ancora buone. Se infine il record non entra né nella cache della CPU, né nella TLB, ma entra nella cache del sistema operativo, le prestazioni rimangono accettabili, altrimenti degradano. Parametri -a: è la prima modalità automatica di IOzone. Produce un output che copre tutte le operazioni sui file partendo da un buffer di 4k fino a 16M per file da 64k a 512M -A: è la seconda modalità automatica di IOzone, più completa dell operazione -a ma richiede molto più tempo -b filename: IOzone al termine della sue esecuzione creerà un file Excel contenente i risultati del benchmark -B: usa file mmap(2) -c: misura il tempo di esecuzione della close(2) -C: misura i byte trasferiti da ogni figlio nel caso si esegua un throughput test

49 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM47 Figura 6.1: esecuzione di iozone. -d #: setta # microsecondi passati fuori dalla barriera: durante un throughput test, tutti i thread o processi sono forzati verso una barriera prima dell inizio del test. Normalmente, tutti i thread o processi sono rilasciati nello stesso momento. Questa opzione permette di settare un ritardo di rilascio tra un thread o processo e l altro -D: usa msync(ms ASYNC) su file mmap(2) -e: misura il tempo di esecuzione di fsync(2) e fflush(3) -E: viene utilizzata per testare determinate estensioni. Usa interfacce pread(2). -f filename: usa il file specificato per condurre i test -F filename filename filename...: specifica più file temporanei per condurre test relativi al throughput. Il numero dei nomi deve essere uguale al numero dei processi o thread specificati -g #: setta la taglia massima in Kbytes per le modalità automatiche

50 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM48 -G: utilizza msync(ms SYNC) su file mmap(2) -h: mostra una schermata d aiuto -H #: utilizza un I/O POSIX asincrono per # volte -i #: utilizzato per specificare che test eseguire. 0=write, rewrite 1=read, re-read 2=random-read, write 3=Read-backwards 4=Re-write-record 5=stride-read 6=fwrite, re-fwrite 7=fread, Re-fread 8=random mix 9=pwrite, Re-pwrite 10=pread, Re-pread 11=pwritev, Re-pwritev 12=preadv, Re- preadv -I: utilizza DIRECT I/O per tutte le operazioni -j #: setta il passo in millisecondi per la lettura pari a # record size per il test stirde read -J #: setta un ritardo pari a # in millisecondi tra una operazione di I/O e l altra -k #: usa # volte input output POSIX asincrono senza l utilizzo di bcopy(3) -K: genera accessi random durante il testing normale -l #: setta il numero minimo di processi da eseguire durante un throughput test

51 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM49 -L #: setta la dimensione della cache a # bytes -m: impone ad IOzone di utilizzare più buffer interni -M: IOzone con questa opzione chiamerà la uname(1) per stampare a video alcune caratteristiche del sistema -n #: setta la dimensione minima in Kbytes per i file utilizzati durante un test in auto mode -N: restituisce i risultati in microsecondi per ogni operazione -o: impone write sincrone sul disco (O SYNC) -O: restituisce risultati in secondi -p: prima di ogni operazione, se questa opzione è stata scelta, le cache del processore vengono invalidate -P #: collega ogni processo/thread con un determinato processore, partendo dalla CPU # -q #: setta la record size massima in Kbytes per l auto mode -Q: crea report di offset e latenza. Il file generato può essere associato con qualsiasi package grafico per essere rappresentato -r #: viene utilizzato per specificare la taglia del record da testare in Kbytes -R: genera un report Excel -s #: viene utilizzato per specificare la taglia dei file da testare in Kbytes -S #: setta la cache del processore a # Kbytes -t #: permette ad IOzone di eseguire test per misurare il throughput -T: utilizza la libreria pthread per effettuare test sul throughput -u #: setta il numero di processi massimi pari a #

52 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM50 -U mountpoint: mount point da smontare e rimontare tra un test e l altro -v: mostra la versione di IOzone -V #: specifica il pattern da scrivere nei file temporanei. -w: evita di cancellare i file utilizzati durante i test una volta terminati questi ultimi. -W: blocca l accesso ai file quando è in esecuzione una lettura o una scrittura. -x: elimina la barriera utilizzata durante un throughput test -X filename: utilizza questo file per scrivere la telemetria -y #: setta la taglia minima di ogni record in Kbytes per l auto mode -Y filename: utilizza questo file per leggere la telemetria -z: da utilizzare assieme all opzione -a per testare tutte le possibili taglie del record -Z: permette di utilizzare un mix di I/O basato su mmap e di I/O basato su file. -+m filename: utilizza il file specificato in filename per apprendere informazioni sui client del cluster che si stà testando -+n: nessun re-test. Vieta l esecuzione di un altro processo IOzone dopo l esecuzione del test corrente -+N: con questa opzione permette la non cancellazione del file utilizzato nel test precedente, il file in questione verrà utilizzato per il corrente test. -+u: misura la percentuale d uso della CPU -+d: abilita la modalità diagnostica. Questa opzione è utile se si sospetta che qualche sottosistema dedicato all I/O sia compromesso

53 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM51 -+p percentread: setta la percentuale di thread/processi che vengono generati durante un random read test. -+r: utilizza i flag O RSYNC e O SYNC per tutti i test di I/O -+t: abilita il test della rete. Richiede l opzione -+m -+A: abilita madvise(2), stampando un report per ogni categoria listata di seguito: 0=normal 1=random 2=sequential 3=dontneed 4=willneed Richiede l opzione -B Bonnie Bonnie esegue una serie di test su un file di taglia fissata. Se essa non viene specificata, Bonnie utilizza un file di 100Mb per i propri test. Bonnie può lavorare con puntatori a 64 bit se l architettura lo permette. Per ogni test Bonnie crea un report che mostra i byte per secondo elaborati, i secondi di utilizzo della CPU e la percentuale di utilizzo della CPU lato utente. I test effettuabili utilizzando Bonnie sono i seguenti e si dividono in tre categorie: output sequenziale, input sequenziale e random seek. Output sequenziale Per-carattere: il file viene scritto utilizzando la funzione putc() della libreria stdio.h. Il ciclo di scrittura è sufficientemente piccolo da sfruttare la cache della CPU. L overhead della CPU, riscontrato da questo test, è dovuto al codice della stdio più la gestione dello spazio da parte del sistema operativo Blocco: il file è creato utilizzando una write(2). L utilizzo della CPU è dovuto solo alla gestione da parte del sistema operativo dello spazio su disco

54 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM52 Figura 6.2: esecuzione di bonnie++. Rewrite: ogni chunk (di taglia 16384) del file è letto con una read(2), sporcato e riscritto con una write(2), ovviamente è richiesta una lseek(2). Dato che non vi è alcuna allocazione di nuovo spazio, l I/O è ben localizzato, questo test può essere utilizzato per verificare l utilizzo effettivo della cache da parte del file system e per misurare la velocità di trasferimento dei dati Input sequenziale Per-carattere: questo test utilizza getc() della libreria stdio.h. Ancora una volta il ciclo di lettura è sufficientemente piccolo. Questo test dovrebbe esercitare solo i meccanismi di input sequenziale Blocco: questo test utilizza read(2). Questo è un test puro di input sequenziale Random seek Questo test fa girare quattro SeekProcCount in parallelo, che eseguono un totale di 4000 lseek() ad una locazione random. Tale locazione viene calcolata utilizzando la funzione random() nei sistemi bsd, drand48() nei sistemi system V. In ogni caso, il blocco è letto con una read(2). Nel 10% dei casi, il blocco è sporcato e riscritto con una write(2). Vengono lanciati più processi SeekProcCount per assicurarsi che vi sia sempre una seek in coda.

55 CAPITOLO 6. SOFTWARE PER IL BENCHMARKING DI FILE SYSTEM53 Figura 6.3: output classico di un test randomio. In ogni sistema Unix il numero effettivo di chiamate a lseek(2) decresce asintoticamente verso 30 al secondo, una volta finito l effetto della cache [5] Bonnie++ Bonnie++ è una suite di benchmark progettata ed implementata per testare dischi rigidi e file system, basata su Bonnie e scritta in C++. Il ruolo principale di Bonnie++ è quello di simulare accessi al disco che produrrebbe un database: creazione, lettura, cancellazione e modifica di file più grandi di un gigabyte. Non vi è molta documentazione a riguardo di questa suite, ma la caratteristica fondamentale è la capacità di estendere le funzionalità di Bonnie, elencate nel paragrafo precedente, su file più grandi di 1GB. Bonnie++ inoltre offre la possibilità di testare le system call creat(), stat() e unlink() [6]. La presentazione dei dati rilevati è di tipo schematico e riassuntivo come mostrato in figura Randomio Randomio è un microbenchmark multi-thread per misurare le prestazioni di un file system sottoposto a più operazioni random (read e write). E stato sviluppato per essere semplice e visualizzare risultati in forma tabellare come mostrato in figura 6.3. L ultima versione rilasciata risale al 2010 ed è compilabile con sistemi unix-like e unix-based [7] PostMark PostMark è stato disegnato per costruire un pool di grandi file in continua mutazione e misurare il tempo per effettuare una operazione sugli stessi simulando il workload di un mail server. PostMark genera un pool iniziale di file testuali di dimensione casuale configurabile tramite due parametri, un lower bound ed un upper bound. Inoltre