Was ist das leistungsstärkste Linux-Dateisystem zum Speichern vieler kleiner Dateien (Festplatte, nicht SSD)?

43

Ich habe einen Verzeichnisbaum, der viele kleine Dateien und eine kleine Anzahl größerer Dateien enthält. Die durchschnittliche Größe einer Datei beträgt ungefähr 1 Kilobyte. Der Baum enthält 210158 Dateien und Verzeichnisse (diese Nummer wurde durch Ausführen ermittelt find | wc -l).

Ein kleiner Prozentsatz der Dateien wird mehrmals pro Woche hinzugefügt, gelöscht oder neu geschrieben. Dies gilt sowohl für kleine Dateien als auch für (wenige) größere Dateien.

Die Dateisysteme, die ich ausprobiert habe (ext4, btrfs), haben einige Probleme mit der Positionierung von Dateien auf der Festplatte. Über einen längeren Zeitraum werden die physischen Positionen von Dateien auf der Festplatte (rotierende Medien, keine Solid-State-Festplatten) immer zufälliger verteilt. Die negative Konsequenz dieser zufälligen Verteilung ist, dass das Dateisystem langsamer wird (z. B. 4-mal langsamer als ein frisches Dateisystem).

Gibt es ein Linux-Dateisystem (oder eine Methode zur Dateisystemwartung), das nicht unter diesem Leistungsabfall leidet und in der Lage ist, ein stabiles Leistungsprofil auf einem rotierenden Medium aufrechtzuerhalten? Das Dateisystem kann unter Fuse ausgeführt werden, es muss jedoch zuverlässig sein.

linux filesystems performance

Wenn Sie wissen, welche Dateien groß sein werden / sich nicht sehr oft ändern und welche klein sein werden / sich häufig ändern, möchten Sie möglicherweise zwei Dateisysteme mit unterschiedlichen Optionen erstellen, die für jedes Szenario besser geeignet sind. Wenn Sie möchten, dass sie zugänglich sind, da sie Teil derselben Struktur waren, können Sie mit mount, symlinks einige Tricks ausführen.

— Marcin

Ich bin ziemlich überrascht zu wissen, dass BTRFS (mit Copy-on-Write-Funktion) für Sie im Laufe der Zeit nur schleppend funktioniert hat. Ich bin neugierig darauf, dass die Ergebnisse von Ihnen geteilt werden und sich möglicherweise gegenseitig dabei helfen, die Leistung zu optimieren.

— Nikhil Mulley

Unter Linux gibt es ein neues Tier-Online-ZFS, das im einheitlichen Modus und in Sicherungsimplementierungen verfügbar ist, falls Sie es sich ansehen möchten.

— Nikhil Mulley

Ich habe zfs einmal unter Linux ausprobiert und war ziemlich instabil. Das Dateisystem konnte ziemlich oft vollständig gesperrt werden. Box würde funktionieren, aber jeder Zugriff auf den FS würde hängen bleiben.

— Patrick

Ähnliches post serverfault.com/questions/6711/…

— Nikhil Mulley

47

Performance

Ich habe einen kleinen Benchmark ( Quelle ) geschrieben, um herauszufinden, welches Dateisystem mit hunderttausenden kleiner Dateien am besten funktioniert:

Erstellen Sie 300000 Dateien (512B bis 1536B) mit Daten aus / dev / urandom
Schreiben Sie 30000 zufällige Dateien um und ändern Sie die Größe
30000 sequentielle Dateien lesen
30000 zufällige Dateien lesen
lösche alle Dateien
Synchronisiere und lösche den Cache nach jedem Schritt

Ergebnisse (durchschnittliche Zeit in Sekunden, niedriger = besser):

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

Ergebnis:
Während Ext4 insgesamt eine gute Leistung zeigte, war ReiserFS beim Lesen von sequentiellen Dateien extrem schnell. Es stellte sich heraus, dass XFS mit vielen kleinen Dateien langsam ist - Sie sollten es für diesen Anwendungsfall nicht verwenden.

Fragmentierungsproblem

Die einzige Möglichkeit, zu verhindern, dass Dateisysteme Dateien über das Laufwerk verteilen, besteht darin, die Partition so groß zu halten, wie sie wirklich benötigt wird. Achten Sie jedoch darauf, die Partition nicht zu klein zu machen, um eine Fragmentierung der Dateien zu verhindern. Die Verwendung von LVM kann sehr hilfreich sein.

Weitere Lektüre

Das Arch Wiki hat einige großartige Artikel, die sich mit der Leistung des Dateisystems befassen:

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

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

— Taffer
quelle

4

Sie sollten angeben, auf welcher Version des Kernels dieser Vergleich basiert. XFS hat einige sehr bedeutende Geschwindigkeitsverbesserungen in einem der letzten Kernel erhalten (ich denke, es war 2.6.31, aber zitiere mich nicht dazu).

— Patrick

1

btrfs macht intern deinen lvm trick. Es ordnet kleinere Teile der Festplatte zu und platziert Dateien in diesen Teilen. Anschließend ordnet es nur dann einen weiteren Teil der Festplatte zu, wenn die vorhandenen Teile voll sind.

— Psusi

1

Das gilt für jedes Dateisystem. Aus diesem Grund verwenden Anwendungen Dinge wie fsync ().

— Psusi

2

@taffer, das ist es. Die Transaktionen haben den gleichen Effekt wie das Journal in anderen Dateisystemen: Sie schützen die fs-Metadaten. Theoretisch können sie von Anwendungen in der von Ihnen beschriebenen Weise verwendet werden. Derzeit gibt es jedoch keine API, die es Anwendungen ermöglicht, Transaktionen zu öffnen und zu schließen.

— Psusi

1

@taffer Ihr "aktueller Benchmark" ist ab April 2015 über drei Jahre alt und verwendet XFS nur mit Standardoptionen. Dies datiert xfsprogs 3.2.3 vor, wodurch XFS v5 zum Standard und zu allen Vorteilen wird, die es mit sich bringt. Es wurde auch nicht mit -m finobt = 1 formatiert. Dies ist ein Game-Changer für die XFS-Leistung mit kleinen Dateien und umfangreichen Metadaten-Updates. Nein, es gibt keine Silberkugeln, aber es ist nicht ratsam, Ihre Meinung auf alte Benchmarks zu stützen, insbesondere wenn wichtige leistungsverändernde Funktionen ignoriert, nicht verfügbar oder deaktiviert wurden.

— Jody Lee Bruchon

7

Ich benutze ReiserFS für diese Aufgabe, es ist speziell für den Umgang mit vielen kleinen Dateien gemacht. Es gibt einen leicht zu lesenden Text im funtoo Wiki.

ReiserFS verfügt auch über eine Reihe von Funktionen, die speziell auf die Verbesserung der Leistung kleiner Dateien abzielen. Im Gegensatz zu ext2 reserviert ReiserFS keinen Speicherplatz in festen 1-k- oder 4-k-Blöcken. Stattdessen kann es die exakte Größe zuweisen, die es benötigt.

— Baarn
quelle

1

Es gibt auch Stabilitätsprobleme mit ReiserFS - also haben RH und SuSE diese FS fallen gelassen. Nach dem Prinzip (BTree-based-FS) sollte BTRFS vergleichbar sein.

— Nils

6

Die Leistung von ext4 sinkt nach 1-2 Millionen Dateien in einem Verzeichnis. Siehe diese Seite http://genomewiki.ucsc.edu/index.php/File_system_performance, erstellt von Hiram Clawson an der UCSC

— Max
quelle

0

XFS ist bekannt dafür, dass es in solchen Situationen sehr gut funktioniert. Dies ist ein Teil des Grundes, warum wir es bei meiner Arbeit für unsere Mail-Stores verwenden (die Hunderttausende von Dateien in einem Verzeichnis enthalten können). Es hat eine bessere Fehlertoleranz als ReiserFS, wird viel häufiger verwendet und ist im Allgemeinen ein sehr ausgereiftes Dateisystem.

Darüber hinaus unterstützt XFS die Onlinedefragmentierung. Es wird jedoch eine Technik mit verzögerter Zuweisung verwendet, die zunächst zu einer geringeren Fragmentierung (im Vergleich zu anderen Dateisystemen) führt.

— Patrick
quelle

20

XFS ist bekannt dafür, dass es in solchen Situationen sehr gut funktioniert. [Zitat benötigt]

— Taffer

8

Ähm, xfs ist besonders bekannt für das Gegenteil: mit großen Dateien sehr gut zu arbeiten, aber mit kleinen nicht so gut! Schauen Sie sich zum Beispiel diesen umfassenden Benchmark an (oder springen Sie direkt zum Fazit auf Seite 10 ^^): ilsistemista.net/index.php/linux-a-unix/…

— Levite

1

@Levit Ich glaube, Sie haben diesen Bericht falsch gelesen. Der Bericht zeigt sehr deutlich, dass XFS bei zufälligen E / A-Vorgängen eine sehr gute Leistung erbringt. Abgesehen davon geht der Bericht jedoch nicht auf die Art des Szenarios in dieser Frage ein, viele Dateien. Zufällige E / A ist eine Sache, bei einer großen Anzahl von Dateien fällt ext * ins Gesicht.

— Patrick

2

Der einzige Ort, an dem XFS wirklich besser ist, sind die zufälligen Lese- / Schreibvorgänge (immer noch seltsam, dass ein wirklich zufälliges Lesemuster auf einer mechanischen Festplatte 10 MB / s erreichen kann) (imho)), während auf Seite 7 genau das gezeigt wird, was ich zuvor gesagt habe, ist XFS wirklich gut im Umgang mit großen Dateien! Schauen Sie sich die Seiten 3 und 5 an, besonders auf Seite 3 können Sie feststellen, dass kleine Dateien nicht so gut verarbeitet werden wie ext! Ich habe zwar wirklich nichts gegen XFS, aber von dem, was Sie so ziemlich überall finden, ist es nicht das beste Optiom für viele kleine Dateien, ist alles, was ich sage!

— Levite

5

XFS kann auch bei großen Dateien extrem langsam sein, wenn diese Dateien über einen längeren Zeitraum zufällig / langsam mit kleinen Blöcken erweitert werden. (Das typische syslogdMuster.) Zum Beispiel habe ich an meiner Seite bei einem XFS-über-MD-Setup gerade festgestellt, dass das Entfernen einer 1,5-GB-Datei 4,75 Minuten (!) Dauerte, während das Festplattenlaufwerk mit einer Schreibrate von 100 Transaktionen / s begrenzt war von mehr als 2 MB / s. Dies wirkt sich auch stark auf die Leistung anderer paralleler E / A-Vorgänge auf demselben Laufwerk aus, da das Laufwerk bereits ausgelastet ist. Ich habe so etwas noch nie in einem anderen FS gesehen (oder in Benchmarks getestet).

— Tino,