Diarium Neminis

Ritenevo questo articolo molto interessante, visto il tema che ogni tanto ricorre, sulla scelta del filesytem più adatto a migliorare le prestazioni del sistema. Per tanto, ho deciso di tradurlo, mentre lo leggevo, così da renderlo disponibile anche per i più “pigri”.

Ci sono molti test che confrontano i file system di Linux in giro per la rete. Molti di essi, però, sono fatti con vecchie versioni del Kernel oppure basati su task artificiali. Il benchmark che segue invece è basato su 11 operazioni direttamente collegate all’ambiente lavorativo di ogni giorno, usando hardware di vecchia generazione (Pentium II/III, hard disk EIDE).

Perché un altro benchmark?

Ho trovato due benchmark basati su kernel 2.6, ma entrambi hanno qualche mancanza. Benoit (2003) ha implementato 12 test usando file grandi (1GB+) su un PII@500Mhz con 512MB di RAM. E’ un test dal quale è possibile ricavare molte informazioni, ma è stato fatto agli albori della serie 2.6 del kernel ed è troppo focalizzato sulle aree che manipolano esclusivamente file grandi (multimedia, ambiente scientifico, database, etc.). L’altro test, di Piszcz (2006), ci presenta 21 task che simulano una varietà di operazioni su file, usando un PIII@500Mhz con 768MB RAM e 400 GB EIDE-133 hard disk. Questo test stressa abbastanza soddisfacentemente il kernel 2.6, ma dato che si basa su task “artificiali” (ovvero, copia e rimozione di 10000 directory vuote, etc.) potrebbe essere difficile ricavare delle conclusioni che valgano per un ambiente di lavoro “reale”.

Per tanto, l’obiettivo del presente benchmark è completare il lavoro di Piszcz (2006), focalizzondosi esclusivamente su operazioni classiche dell’ambiente di lavoro con file server di fascia bassa (vedere Descrizione dei Task, più avanti).

Configurazioni

* Hardware Processor : Intel Celeron 533
* RAM : 512Mb RAM PC100
* Motherboard : ASUS P2B
* Hard drive : WD Caviar SE 160Gb (EIDE 100, 7200 RPM, 8 MB Cache)
* Controller : ATA/133 PCI (Silicon Image)

* OS Debian Etch (kernel 2.6.15), aggiornata il 18 Aprile 2006
* Tutti i servizi opzionali stoppati (cron,ssh,samba,etc.)

* Filesystems Ext3 (e2fsprogs 1.38)
* ReiserFS (reiserfsprogs 1.3.6.19)
* JFS (jfsutils 1.1.8)
* XFS (xfsprogs 2.7.14)

Descrizione dei Task

Operazioni su file grandi (Immagini ISO, 700MB)
* Copia di un ISO da un secondo disco al disco di test
* Copia della stessa ISO in un’altra locazione del disco di test
* Cancellazione di entrambe le copie dell’ISO

Operazioni su un albero di file (7500 file, 900 directory, per un totale di 1.9GB)
* Copia dell’albero di file da un secondo disco al disco di test
* Copia dello stesso albero di file in un’altra locazione del disco di test
* Cancellazione dei entrambe le copie

Operazioni all’interno dell’albero di file
* Elenco ricorsivo di tutti i contenuti dell’albero di file e salvataggio dell’elenco sul disco di test
* Trovare file che corrispondono a una specifica combinazione di caratteri jolly

Operazioni su File system
* Creazione di un file system (mkfs) (tutti i FS sono stati creati con le opzioni di default)
* Montaggio del filesystem
* Smontaggio del filesystem

La sequenza di 11 task (dalla creazione del FS allo smontaggio dello stesso) è stata eseguita da uno script Bash che è stato completato tre volte (la media è riportata). Ogni sequenza è durata circa 7 minuti. Il tempo per completare un task (in secondi), la percentuale di CPU dedicata al task e il numero massimo e minimo di pagefault avvenuti durante l’esecuzione del task sono stati calcolati dall’utility GNU time (versione 1.7).

Risultati

Capacità delle partizioni

La capacità delle partizioni iniziale (dopo la creazione del file system) e residua (dopo l’eliminazione di ogni file) è stata calcolata come il rapporto tra il numero di blocchi disponibili e quello di blocchi totali di una partizione. Ext3 è risultato avere la peggiore capacità iniziale (92.77%), mentre gli altri file system preservavano quasi la totalità della loro capacità (ReiserFS = 98.33%, JFS = 99.82%, XFS = 99.95%). E’ interessante notare che la capacità residua di Ext3 e ReiserFS resta la stessa di quella iniziale, mentre JFS e XFS perdono circa lo 0.02%; ciò ci fa capire come questi FS possano crescere dinamicamente ma abbiano qualche (piccolissima) difficoltà a tornare esattamente alle condizioni iniziali dopo la cancellazione totale dei file.
Conclusione: per usare della capacità della tua partizione, scegliete ReiserFS, JFS o XFS.

Creazione del file system, montaggio e smontaggio

La creazione del FS sulla partizione di test da 20GB ha impiegato un esagerato 14.7 secondi per Ext3, in confronto ai 2 secondi (o meno) per gli altri FS (ReiserFS = 2.2, JFS = 1.3, XFS = 0.7).
Mentre per l’operazione di montaggio, ReiserFS impiega da 5 a 15 volte di più (2.3 secondi) rispetto agli altri (Ext3 = 0.2, JFS = 0.2, XFS = 0.5); è ancora ReiserFS a perdere durante lo smontaggio, con un tempo (2.3 secondi) che è due volte quello degli altri FS. Tutti i FS usano una quantità di CPU più o meno uguale per creare il FS (tra il 59% di ReiserFS e il 74% di JFS) e per montarlo (tra il 6% e il 9% di CPU). Per lo smontaggio, Ext3 e XFS impiegano 2 volte il tempo di CPU (37% e 45%) rispetto a ReiserFS e JFS (14% e 27%).
Conclusioni: per un veloce iter di crea/monta/smonta, scegliete JFS o XFS.

Operazioni su grandi file (immagine ISO, 700MB)

La copia iniziale di un file grande impiega di più su Ext3 (38.2 secondi) e ReiserFS (41.8 sec) confrontato con JFS e XFS (35.1 e 34.8 secondi). Ricopiare il file sullo stesso disco avvantaggia XFS (33.1 sec), confrontato con gli altri FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). La cancellazione della ISO è 100 volte più veloce su JFS e XFS (0.02 secondi per entrambi); ReiserFS impiega 1.5 secondi mentre Ext3 addirittura 2.5 secondi. Tutti i FS impiegano un tempo di CPU assimilabile per quanto riguarda l’operazione di copia (tra il 46 e il 51 per cento di CPU) e la ri-copia (tra il 38% e il 50%) della ISO. ReiserFS perde nettamente sulla cancellazione, dove impiega il 49% del tempo di CPU per cancellare la ISO, rispetto agli altri FS che impiegano circa il 10% della CPU. E’ chiaro che JFS tende ad usare meno CPU degli altri FS (circa il 5-10% in meno). Il numero minimo di page fault è abbastanza simile tra i FS (da 600 di XFS a 661 di ReiserFS).
Conclusioni: per operazioni veloci su grand file, scegliete JFS o XFS. Se vi interessa particolarmente minimizzare l’uso di CPU, allora optate per JFS.

Operazioni su un albero di file (7500 file, 900 directory, 1.9Gb)

La copia iniziale dell’albero è stata più veloce per Ext3 (158.3 sec) e XFS (166.1), in confronto a ReiserFS e JFS (172.1 and 180.1). Risultati simili sono stati osservati durante la ri-copia sullo stesso disco, che ha avvantaggiato Ext3 (120 sec) rispetto agli altri FS (135.2 per XFS, 136.9 per ReiserFS, 151 per JFS). La cancellazione dell’albero è 2 volte più lenta su Ext3 (22 sec), rispetto a ReiserFS (8.2), XFS (10.5) e JFS (12.5). Tutti i FS usano più o meno lo stesso tempo di CPU per l’operazione di copia (27-36%) e la ri-copia (tra il 29% di JFS e il 45% di ReiserFS) dell’albero di file. Sorprendentemente, ReiserFS e XFS usano molta più CPU per rimuovere l’albero di file (86% e 65%) rispetto agli altri FS (15% circa sia per Ext3 che JFS). Ancora una volta JFS mostra la sua tendenza a usare meno CPU di tutti gli altri FS. Il numero minimo di page fault è significativamente più alto per ReiserFS (5843) rispetto alla media degli altri FS (tra 1400 e 1490). Questa differenza sembra essere dovuta al più alto numero di page fault (da 5 a 20 volte in più) di ReiserFS durante le operazioni di ri-copia e cancellazione.
Conclusioni: per avere velocità nelle operazioni su alberi di file, scegliete Ext3 or XFS. Benchmark di altri autori consigliavano di usare ReiserFS per operazioni su file piccoli. Tuttavia, i risultati di questo test effettuato su un albero di file di varie dimensioni (10KB - 5MB) indicano Ext3 o XFS come più appropiati per operazioni “reali”. Nonostante JFS minimizzi l’uso di CPU, in questo caso lo fa offrendo una maggiore latenza sulle operazioni.

Elenco delle directory e ricerca file nell’albero di file precedente

L’elenco ricorsivo completo è stato prodotto più velocemente da ReiserFS (1.4 sec) e XFS (1.8); per Ext3 abbiamo un 2.5 sec mentre JFS sale a 3.1 sec. Risultati simili sono stati ottenuti durante la ricerca di file, dove ReiserFS (0.8 sec) e XFS (2.8) hanno mantenuto risultati migliori rispetto a Ext3 (4.6 sec) e JFS (5 sec). Ext3 e JFS hanno impiegato un tempo di CPU simile nell’elenco dei file (35%) e nella ricerca (6%). XFS impiega più tempo di CPU per l’elenco (70%) mentre ottiene un buon tempo di CPU nella ricerca (10%). ReiserFS si mosra come il più avido di CPU con un 71% per l’elenco e 36% per la ricerca. Ancora una volta, il numero minimo di page fault è 3 volte maggiore per ReiserFS (1991) rispetto agli altri (704-712).
Conclusioni: i risultati mostrano che, per questi compiti, i filesystem in esame possono essere raggruppati come “Veloci ma avidi di CPU” (ReiserFS e XFS) e “Lenti ma meno avidi di CPU” (Ext3 e JFS). XFS sembra un buon compromesso, con risultati relativamente veloci, uso della CPU moderato, e un accettabile frequenza di page fault.

Conclusioni generali

I risultati sono sulla stessa lunghezza d’onda delle osservazioni di Piszcz (2006) circa la ridottà capacità disco di Ext3, il lungo tempo di montaggio di ReiserFS e il lungo tempo di creazione di Ext3. In più, come in questo test, entrambi i benchmark citati all’inizio hanno osservato che JFS è il filesystem che usa meno CPU. Mentre questo benchmark sembra essere il primo a mettere in evidenza l’enorme quantità di page fault causati da ReiserFS durante le usuali operazioni su file.
Basandosi sui test fatti per questo benchmark, XFS sembra essere il filesystem adatto per un file server casalingo (quindi anche un desktop, ndNemo) o per una piccola azienda:

* XFS usa la capacità massima dell’hard disk
* XFS è il più veloce nella creazione/montaggio/smontaggio
* XFS è il più veloce nelle operazioni su file grandi (>500MB)
* XFS ottiene un ottimo secondo posto nelle operazioni su alberi di file con grandezze che oscillano tra il “piccolo” e il “moderato”
* XFS ha un buon rapporto tra utilizzo di CPU e tempo impiegato per le operazioni di elenco ricorsivo di directory e ricerca file
* XFS non è il FS meno avido di CPU, ma il suo utilizzo delle risorse resta accettabile per hardware di vecchia generazione.

Nonotante Piszcz (2006) non raccomandi esplicitamente XFS, egli conclude con “Personalmente, scelgo ancora XFS per le prestazioni e la scalabilità”. Posso solo supportare questa conclusione (e anche io, ndNemo).

Riferimenti

Benoit, M. (2003). Linux File System Benchmarks.
Piszcz, J. (2006). Benchmarking Filesystems Part II. Linux Gazette, 122 (January 2006).