Log structured-file-system

Introduzione Log-structured ﬁle system Analisi delle prestazioni Conclusioni Riferimenti
The Design and Implementation of a
Log-Structured File System
Gioele Ciaparrone, Luca Vitale
Sistemi Operativi Avanzati A.A. 2015/2016
Corso di Laurea Magistrale in Informatica
Prof. Giuseppe Cattaneo
29 Aprile 2016
Università degli Studi di Salerno Log-Structured File System 29 Aprile 2016 1 / 51

Overview
1 Introduzione
Autori
Contesto storico
Deﬁnizione del problema
2 Log-structured ﬁle system
Introduzione
Gestione dello spazio libero
Crash recovery
3 Analisi delle prestazioni
Sistema utilizzato per i benchmark
Risultati
4 Conclusioni
5 Riferimenti

Autori
Mendel Rosenblum
1992: Ph.D. in CS all’University of
California, Berkeley
1998: Cofondatore di VMware
Attualmente professore a Stanford nei
dipartimenti di Computer Science ed
Electrical Engineering

Autori
John Ousterhout
1980: Ph.D. in CS alla Carnagie Mellon
University
1994-1998: sviluppatore del linguaggio
Tcl alla Sun Mycrosystems
Attualmente professore di CS alla
Stanford University e chairman di
Electric Cloud Inc.

Contesto storico
Breve storia dei ﬁle system
1968 – George 3 [6]
1980 – FAT12 [4]
1984 – FAT16 [4], Berkeley Fast File System [9]
1992 – Sprite Log-structured File System (LFS) [10]
1993 – NTFS [8], ext2 [1]
1996 – FAT32 [4]
2001 – ext3 [2]
2006 – ext4 [3]

Cos’è un ﬁle system
File system
Un ﬁle system è l’insieme delle strutture dati necessarie per la
memorizzazione, l’organizzazione gerarchica, la
manipolazione, la navigazione, l’accesso e la lettura dei dati.

Problema
Miglioramento velocità CPU vs. latenza accesso al disco
Le applicazioni tenderanno ad essere più I/O bound
Fondamentale ottimizzare l’utilizzo del disco

Design di un ﬁle system
Il design di un ﬁle system è guidato da due forze fondamentali:
Tecnologia
Workload

Tecnologia
Tre componenti tecnologiche determinano l’efﬁcienza di un ﬁle
system:
Velocità della CPU
Capacità e latenza della RAM
Bandwidth e tempo di accesso al disco

Workload
Due tipologie di workload:
Ufficio: accessi casuali a tanti piccoli file
Supercomputing: accesso sequenziale a grandi file

Problemi dei file system tradizionali
Dati sparsi sul disco
In UNIX FFS 5 seek per creare un file
Utilizzato solo 5% della bandwidth
Operazione di write sincrona
Scrittura di tanti piccoli file rallentata
Soluzione: Sprite LFS

Introduzione
Sprite LFS
Log-structured ﬁle system
È un ﬁle system in cui dati e metadati vengono scritti
sequenzialmente in un buffer circolare, chiamato log.
Ogni sequenza di cambiamenti viene bufferizzata in cache
e poi scritta sequenzialmente sul log (disco)
Miglioramento delle performance in scrittura
Si evitano sincronizzazioni
Una sola seek per ogni svuotamento della cache

Introduzione
Lettura di un file I
La lettura di un file non richiede accesso sequenziale al log
Per individuare i blocchi di un file si usa l’inode
inode
È una struttura dati sul file system che archivia e descrive
attributi base di file e directory, tra cui anche la posizione dei
blocchi di dati che li compongono.
L’inode utilizzato da Sprite LFS ha la stessa struttura di
quello di Unix FFS

Introduzione
Lettura di un file II
Ad ogni file (o directory) è associato un inode
A differenza di Unix, gli inode non sono in posizioni fisse
Si usa quindi un’inode map, che mantiene gli indirizzi fisici
degli inode per ogni file
I blocchi dell’inode map sono scritti nel log e il loro indirizzo
è salvato in una regione fissa del disco
L’inode map viene mantenuta in cache, evitando frequenti
accessi al disco

Introduzione
Esempio: creazione di due ﬁle

Problema dello spazio libero
Il problema principale di un log-structured ﬁle system è
quello di mantenere grandi sezioni contigue di spazio
libero su disco
Esistono due opzioni per gestire la frammentazione dello
spazio libero:
Threading
Copying

Threading e copying I

Threading e copying II
Lo svantaggio del threading è che serve più di una seek
per scrivere dati nel log
Non è più veloce di un ﬁle system tradizionale
Lo svantaggio del copying è che la copiatura dei blocchi di
dati può richiedere molto tempo
Sprite LFS sceglie quindi una combinazione di threading e
copying

Threading e copying III
Il disco viene diviso in grandi sezioni di grandezza ﬁssa
chiamate segmenti
I dati vengono scritti sequenzialmente dall’inizio alla ﬁne di
ogni segmento
Prima di poter riscrivere dati in un segmento, i dati live
devono essere ricopiati fuori da esso
Il threading viene effettuato a livello dei segmenti
Segmenti abbastanza grandi da sfruttare la larghezza di
banda del disco

Meccanismo di pulitura dei segmenti I
Pulitura dei segmenti
È il processo di copia di blocchi di dati live all’esterno di un
segmento.
L’obiettivo è quello di aumentare il numero di segmenti
vuoti
Sprite LFS non utilizza bitmap o liste per tener traccia dei
blocchi liberi

Meccanismo di pulitura dei segmenti II
Processo composto da tre fasi:
Lettura di un certo numero di segmenti
Identificazione dei blocchi di dati live
Riscrittura dei dati live in un numero minore di segmenti
I segmenti letti vengono quindi marcati come puliti e
possono essere utilizzati per la scrittura di nuovi dati
Per identificare i dati live in ogni segmento viene scritto un
segment summary block, che indica per ogni blocco del
segmento l’id del file a cui appartiene, il numero del blocco
e la versione del file

Politiche di pulitura I
1 Quando eseguire la pulitura dei segmenti?
2 Quanti segmenti pulire ogni volta?
3 Quali segmenti pulire?
4 Come raggruppare i blocchi di dati live quando vengono
ricopiati?

Politiche di pulitura II
Le scelte 1 e 2 non hanno inﬂuenzato particolarmente le
prestazioni del sistema
Le scelte 3 e 4 si sono rivelate fondamentali
Per confrontare le prestazioni è stato introdotto il concetto
di write cost, che ci dà un’informazione sulla bandwidth
del disco effettivamente utilizzata per scrivere nuovi dati
write cost =
total bytes read and written
new data written

Politiche di pulitura III
Se per ogni scrittura si effettuasse una pulitura dei
segmenti, avremmo un write cost pari a 2/(1 − u)

Obiettivo
Per migliorare le performance del sistema è necessario
ottenere una distribuzione bimodale della frazione di dati
live dei segmenti
Molti segmenti quasi pieni e molti segmenti quasi vuoti
Per ottenere questa distribuzione vediamo come scegliere
i segmenti da pulire e come raggruppare i dati live ricopiati

Simulazione del sistema I
Sono state simulate le prestazioni del sistema modellando
un file system con tanti file da 4KB ciascuno
Sono stati modificati i file seguendo due pattern diversi:
Uniforme – stessa probabilità di modifica di ogni file
Hot-and-cold – 90% dei file modificati il 10% delle volte e il
restante 10% modificato il 90% delle volte (località)
Scelta greedy dei segmenti da pulire: i più vuoti
I dati live sono stati ricopiati nello stesso ordine nel caso
uniforme e ordinati per età nel caso hot-and-cold

Simulazione del sistema II

Problema della scelta greedy

Soluzione: cost-benefit policy
I segmenti con dati modificati raramente (cold) tendono a
mantenere molto spazio libero per molto tempo
La soluzione è dare più peso allo spazio libero dei
segmenti cold
Politica cost-benefit:
benefit
cost
=
free space generated ∗ age of data
cost
=
(1 − u) ∗ age
1 + u

Effetti della cost-beneﬁt policy I

Effetti della cost-beneﬁt policy II

Crash recovery
Crash recovery
Nei ﬁle system tradizionali in caso di crash del sistema è
necessario effettuare una scansione di tutto il ﬁle system
per risolvere le inconsistenze
Nei LFS è facile determinare la posizione delle ultime
operazioni effettuate sul disco: recovery più veloce
Sprite LFS utilizza due strumenti per la recovery:
Checkpoint
Roll-forward

Crash recovery
Checkpoint I
Checkpoint
È la posizione nel log fino alla quale tutte le strutture dati del file
system sono consistenti e complete.
Dopo aver scritto i dati sul disco, viene aggiornata la
checkpoint region, salvata in una posizione fissa del
disco
La checkpoint region contiene i dati che permettono di
verificare la consistenza del sistema (tra cui data e
posizione dell’ultima operazione effettuata)

Crash recovery
Checkpoint II
Sprite LFS effettua checkpoint a intervalli periodici e
quando il ﬁle system viene smontato
La lunghezza degli intervalli inﬂuenza l’overhead di
scrittura e la quantità di dati da recuperare in caso di crash
Lunghi intervalli: meno overhead, ma più tempo per la
recovery
Brevi intervalli: più overhead, ma minor costo di recovery

Crash recovery
Roll-forward
Invece di scartare tutte le modiﬁche effettuate dopo l’ultimo
checkpoint, possiamo cercare di recuperare i dati
Sprite LFS scansiona quindi i dati dopo l’ultimo checkpoint
(roll-forward)
Utilizza quindi i dati presenti nei segment summary block
per tentare di ripristinare quante più informazioni possibili
Per garantire la consistenza delle directory, utilizza un
directory operation log, che salva le modiﬁche effettuate
alle directory prima di riscrivere gli inode

Implementazione di Sprite LFS
L’implementazione di Sprite LFS non è risultata più
complicata dei ﬁle system tradizionali come Unix FFS
La versione utilizzata per i test non implementava il
roll-forward
Intervallo tra i checkpoint di 30 secondi
Nell’uso di tutti i giorni gli utenti non hanno percepito
differenze con Unix FFS, probabilmente perché le
macchine non erano abbastanza veloci da essere
I/O-bound

Sistema utilizzato I
Benchmark eseguiti su Sun 4/260
CPU con IU Fujitsu SF9010 e FPU
Weitek 1164/1165, 16.67 MHz
32 MB RAM
HDD: Wren IV, bandwidth 1.3 MB/s,
latenza 17.5 ms, 300 MB

Sistema utilizzato II
Confronto tra Sprite LFS e SunOS 4.0.3
Blocchi da 8 KB su SunOS, da 4 KB su Sprite LFS con
segmenti da 1 MB
Multiutente
Caso ottimo: nessuna pulitura dei segmenti durante i
benchmark

Risultati
Performance su ﬁle piccoli

Risultati
Performance su ﬁle grandi

Risultati
Simulazione con overhead di pulitura I
Per valutare l’overhead causato dalla pulitura dei segmenti,
è stato effettuato un test su un sistema reale per un
periodo di 4 mesi

Risultati
Simulazione con overhead di pulitura II

Risultati
Performance di crash recovery
Usato un sistema con intervallo di checkpoint inﬁnito e che
non salvava le modiﬁche alle directory

Conclusioni I
Il principio fondamentale di un log-structured ﬁle system è
quello di scrivere i nuovi dati in cache, per poi scriverli su
disco in un’unica grande operazione di I/O
Massimizzazione della bandwidth usata per scrivere dati
nuovi
È possibile ottenere bassi costi di overhead di pulitura con
la cost-beneﬁt policy

Conclusioni II
Performance migliori dei file system esistenti su piccoli file
Performance simili o migliori su grandi file tranne in pochi
casi (lettura sequenziale di file scritti random)
Sistema più CPU-bound: miglioramento delle performance
con l’aumento delle prestazioni delle CPU

I log-structured file system oggi I
L’idea del log viene sfruttata attualmente nei journaling
file system [5]
NTFS, ext3+, UFS dal 2004
Tuttavia il log mantiene solo le modifiche al file system, ma
non include i blocchi di dati

I log-structured file system oggi II
I log-structured file system sono utili su device che hanno
un numero limitato di scritture in ogni locazione perché
diminuiscono il numero di scritture eseguite nella stessa
locazione [7]
UDF (dischi ottici)
LogFS, YAFFS, F2FS (memorie flash)

Riferimenti I
Ext2.
https://en.wikipedia.org/wiki/Ext2.
Accessed: 2016-04-22.
Ext3.
Accessed: 2016-04-22.
Ext4.
Accessed: 2016-04-22.

Riferimenti II
File Allocation Table.
https:
//en.wikipedia.org/wiki/File_Allocation_Table.
Accessed: 2016-04-22.
Journaling.
https://it.wikipedia.org/wiki/Journaling.
Accessed: 2016-04-27.
List of default ﬁle systems.
https://en.wikipedia.org/wiki/List_of_default_
file_systems.
Accessed: 2016-04-22.

Riferimenti III
List of log-structured ﬁle systems.
https://en.wikipedia.org/wiki/List_of_
log-structured_file_systems.
Accessed: 2016-04-27.
NTFS.
https://en.wikipedia.org/wiki/NTFS.
Accessed: 2016-04-22.
M. K. McCusick, W. N. Joy, S. J. Lefﬂer, and R. S. Fabry.
A Fast File System for UNIX.
1984.

Riferimenti IV
Mendel Rosenblum and John Ousterhout.
The design and implementation of a log-structured ﬁle
system.
1992.

Log structured-file-system

More Related Content

Similar to Log structured-file-system (20)

More from Luca Vitale (11)

Recently uploaded (8)

Log structured-file-system