Qual è il filesystem Linux più performante per archiviare molti piccoli file (HDD, non SSD)?

43

Ho un albero di directory che contiene molti piccoli file e un piccolo numero di file più grandi. La dimensione media di un file è di circa 1 kilobyte. Ci sono 210158 file e directory nella struttura (questo numero è stato ottenuto eseguendo find | wc -l).

Una piccola percentuale di file viene aggiunta / eliminata / riscritta più volte alla settimana. Questo vale per i file piccoli, così come per il (piccolo numero di) file più grandi.

I filesystem che ho provato (ext4, btrfs) hanno alcuni problemi con il posizionamento dei file su disco. Per un periodo di tempo più lungo, le posizioni fisiche dei file sul disco (supporto rotante, non disco a stato solido) vengono distribuite in modo più casuale. La conseguenza negativa di questa distribuzione casuale è che il filesystem sta diventando più lento (come: 4 volte più lento di un nuovo filesystem).

Esiste un filesystem Linux (o un metodo di manutenzione del filesystem) che non soffre di questo degrado delle prestazioni ed è in grado di mantenere un profilo prestazionale stabile su un supporto rotante? Il file system può essere eseguito su Fuse, ma deve essere affidabile.

linux filesystems performance

Se sai quali file saranno grandi / che non cambiano molto spesso e quali saranno piccoli / che cambiano frequentemente, potresti voler creare due filesystem con diverse opzioni su di essi, più adatti a ogni scenario. Se hai bisogno che siano accessibili perché facevano parte della stessa struttura, puoi fare alcuni trucchi con mount, symlink.

— Marcin,

Sono abbastanza sorpreso di sapere che btrfs (con la funzione di copia su scrittura) ti è stato lento per un certo periodo di tempo. Sono curioso di avere i risultati condivisi da te, eventualmente aiutandoci a vicenda in una nuova direzione della messa a punto delle prestazioni.

— Nikhil Mulley,

c'è un nuovo animale online zfs su Linux, disponibile in modalità nativa e implementa fusibili, nel caso in cui volessi dare un'occhiata.

— Nikhil Mulley,

Ho provato zfs su Linux una volta, era abbastanza instabile. Gestito per bloccare completamente il filesystem abbastanza spesso. Box funzionerebbe, ma qualsiasi accesso a FS si bloccherebbe.

— Patrick

Post simile serverfault.com/questions/6711/…

— Nikhil Mulley

47

Prestazione

Ho scritto un piccolo benchmark ( sorgente ), per scoprire quale file system funziona meglio con centinaia di migliaia di piccoli file:

creare 300000 file (da 512B a 1536B) con dati da / dev / urandom
riscrivi 30000 file casuali e modifica le dimensioni
leggere 30000 file sequenziali
leggere 30000 file casuali
elimina tutti i file
sincronizzare e rilasciare la cache dopo ogni passaggio

Risultati (tempo medio in secondi, inferiore = migliore):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Risultato:
mentre Ext4 ha avuto buone prestazioni complessive, ReiserFS è stato estremamente veloce nella lettura di file sequenziali. Si è scoperto che XFS è lento con molti file di piccole dimensioni - non dovresti usarlo per questo caso d'uso.

Problema di frammentazione

L'unico modo per impedire ai file system di distribuire i file sull'unità è quello di mantenere la partizione solo grande quanto è realmente necessaria, ma fare attenzione a non rendere la partizione troppo piccola, per evitare frammenti intrafili. L'uso di LVM può essere molto utile.

Ulteriori letture

Arch Wiki ha alcuni fantastici articoli riguardanti le prestazioni del file system:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

— Taffer
fonte

4

Dovresti specificare su quale versione del kernel stai basando quel confronto. XFS ha ottenuto alcuni miglioramenti della velocità molto significativi in uno dei kernel recenti (penso che fosse 2.6.31, ma non citarmi su questo).

— Patrick,

1

btrfs internamente fa il tuo trucco lvm. Alloca pezzi più piccoli del disco e posiziona i file in quei pezzi, quindi alloca solo un altro pezzo del disco quando i pezzi esistenti si riempiono.

— psusi,

1

Questo è vero per qualsiasi filesystem. Ecco perché le applicazioni usano cose come fsync ().

— psusi,

2

@taffer, lo è. Le transazioni hanno lo stesso effetto del journal in altri filesystem: proteggono i metadati fs. In teoria, possono essere utilizzati dalle applicazioni nel modo in cui descrivi, ma al momento non esistono API per consentire alle applicazioni di aprire e chiudere transazioni.

— psusi,

1

@taffer Il tuo "benchmark recente" è di aprile 2015, ha più di tre anni e utilizza XFS con solo opzioni predefinite. Questo pre-date xfsprogs 3.2.3 che rende XFS v5 il valore predefinito e tutti i vantaggi che porta. Inoltre non è stato formattato con -m finobt = 1, che è un punto di svolta per le prestazioni XFS con file di piccole dimensioni e aggiornamenti di metadati pesanti. No, non ci sono proiettili d'argento, ma basare la tua opinione su vecchi benchmark non è saggio, specialmente quando le principali funzionalità che cambiano le prestazioni sono state ignorate, non disponibili o disabilitate.

— Jody Lee Bruchon,

7

Sto usando ReiserFS per questo compito, è stato creato appositamente per gestire molti file di piccole dimensioni. C'è un testo facile da leggere al riguardo nel wiki di funtoo.

ReiserFS ha anche una serie di funzionalità mirate specificamente a migliorare le prestazioni di file di piccole dimensioni. A differenza di ext2, ReiserFS non alloca spazio di archiviazione in blocchi fissi di uno o quattro k. Al contrario, può allocare le dimensioni esatte di cui ha bisogno.

— Baarn
fonte

1

Ci sono problemi di stabilità anche con ReiserFS - quindi RH e SuSE hanno abbandonato FS. Dal principio (BTree-based-FS) BTRFS dovrebbe essere comparabile.

— Nils,

6

Le prestazioni ext4 diminuiscono dopo 1-2 milioni di file in una directory. Vedi questa pagina http://genomewiki.ucsc.edu/index.php/File_system_performance creato da Hiram Clawson presso UCSC

— Max
fonte

0

XFS è noto per le sue ottime prestazioni in situazioni come questa. Questo è parte del motivo per cui lo usiamo nel mio lavoro per i nostri negozi di posta (che possono contenere centinaia di migliaia di file in 1 directory). Ha una migliore tolleranza agli errori rispetto a ReiserFS, è molto più diffuso ed è generalmente un filesystem molto maturo.

Inoltre, XFS supporta la deframmentazione online. Sebbene utilizzi una tecnica di allocazione ritardata che si traduce in meno frammentazione (rispetto ad altri filesystem) per cominciare.

— Patrick
fonte

20

XFS è noto per le sue ottime prestazioni in situazioni come questa. [citazione necessaria]

— taffer

8

Ehm, xfs è particolarmente noto per il contrario: funziona davvero bene con file di grandi dimensioni, ma non così bene su quelli piccoli! Guarda questo esaustivo benchmark per esempio (o vai

— Levite

1

@Levit Penso che tu stia leggendo male quel rapporto. Il rapporto mostra chiaramente che XFS funziona molto bene per l'Io casuale. Ma a parte questo, il rapporto non affronta il tipo di scenario in questa domanda, molti file. L'IO casuale è una cosa, un gran numero di file è dove ext * cade sulla sua faccia.

— Patrick,

2

L'unico posto in cui XFS è davvero migliore ci sono le operazioni di lettura / scrittura casuali (sembra ancora strano che un modello di lettura davvero casuale su un disco meccanico sia in grado di ottenere 10 MB / s - mi sembra una ottimizzazione che non vola nel mondo reale (imho)), mentre a pagina 7 mostra esattamente quello che ho detto prima, XFS è davvero bravo a gestire file di grandi dimensioni! Guarda le pagine 3 e 5, esp su 3 lo vedi chiaramente gestire piccoli file non così come ext! In realtà non ho nulla contro XFS, ma da quello che trovi praticamente ovunque, non è la migliore opzione per molti piccoli file, è tutto ciò che sto dicendo!

— Levita,

5

XFS può anche essere estremamente lento quando si tratta di file di grandi dimensioni, se questi file vengono estesi in modo casuale / lento con blocchi piccoli per lungo tempo. (Lo syslogdschema tipico .) Ad esempio al mio fianco in una configurazione XFS su MD ho appena osservato che la rimozione di un file da 1,5 GB ha richiesto 4,75 minuti (!) Mentre l'unità disco era bloccata a un limite di 100 transazioni / s a una velocità di scrittura di oltre 2 MB / s. Ciò influisce anche negativamente sulle prestazioni di altre operazioni di IO in parallelo sullo stesso azionamento, poiché l'azionamento è già al massimo. Non ho mai visto nulla di simile in altri FS (o in fase di test nei benchmark).

— Tino,