Was ist das schnellste Dateisystem für Entwickler-Builds?

Ich stelle eine Linux-Box zusammen, die als Build-Server für die kontinuierliche Integration fungiert. Wir werden hauptsächlich Java-Inhalte erstellen, aber ich denke, diese Frage gilt für jede kompilierte Sprache.

Welche Dateisystem- und Konfigurationseinstellungen soll ich verwenden? (Ich weiß zum Beispiel, dass ich dafür keine Zeit benötige!) Der Build-Server verbringt viel Zeit damit, kleine Dateien zu lesen und zu schreiben und Verzeichnisse zu scannen, um festzustellen, welche Dateien geändert wurden.

UPDATE: Datenintegrität hat in diesem Fall eine niedrige Priorität. Es ist nur eine Build-Maschine ... die endgültigen Artefakte werden komprimiert und an anderer Stelle archiviert. Wenn das Dateisystem auf dem Buildcomputer beschädigt wird und alle Daten verloren gehen, können wir es einfach löschen und ein neues Image erstellen. Builds werden wie zuvor fortgesetzt.

Verwenden Sie ext4fs als Basis-Dateisystem mit einigen Beschleunigungsoptionen wie

noatime,data=writeback,nobh,barrier=0,commit=300

Dann mounten Sie eine tmpfs-Ramdisk darüber, damit die während der Builds geschriebenen Dateien die Vorteile der Ramdisk nutzen. Ändern Sie entweder die Build-Prozedur, um die resultierenden Binärdateien am Ende des Builds von den tmpfs zu entfernen, oder führen Sie die tmpfs vor dem Aufheben der Bereitstellung wieder in ext4fs zusammen.

Schnellstes Dateisystem? tmpfs aus verfügbarem RAM mit noatimeset gemountet .

Dies ist nur möglich, wenn Sie über ein Verfahren zum Auschecken aller zum Erstellen Ihres Quellbaums erforderlichen Elemente verfügen (da der Inhalt eines tmpfs-Dateisystems beim Neustart nicht mehr angezeigt wird) und wenn Quelle und Objekte in eine angemessene Ecke Ihres verfügbaren Arbeitsspeichers passen ( mit genug übrig, um Ihren Compiler & Linker ohne Austausch auszuführen). Das heißt, Sie können es nicht übertreffen, aus RAM für Geschwindigkeit zu arbeiten ..

Zur Antwort von Michael Dillon kann ich hinzufügen, dass Sie ext4-Dateisystem mit wenigen Optionen erstellen können:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 bietet Ihnen mehr Inodes pro Größe. Dies ist nützlich, da in Gebäudeumgebungen viele Dateien erstellt werden.

Für Quellen ist eine Unterstützung für die automatische Komprimierung vorzuziehen, dh Reiser4 oder Btrfs . Beide sind "noch nicht für die Produktion", obwohl ich von Leuten gehört habe, die beide FSes stark und glücklich verwenden. :-)

Die nächste Wahl (die ich normalerweise mache) ist Reiser3 , nicht Ext3 . Ext3 kann heutzutage etwas schneller sein, aber Reiser3 hat keine Format-Zeitlimits für i-Nodes und unterstützt das Online-Ändern der Option "data =". Es hat "Tail" -Unterstützung, die das Packen kleinerer Dateien ermöglicht, aber wenn Sie sich Gedanken über die Geschwindigkeit machen, "notail".

Sowohl XFS als auch JFS wären ein Problem für den Fall "viele kleine Dateien", insbesondere wenn Sie sie benötigen.

(Vergessen, EXT4 zu erwähnen: Ja, es ist noch schneller als EXT3. Aber alle oben genannten Einschränkungen von EXT3 sind auch EXT4).

Die von Ihnen beschriebenen Vorgänge geben einige wichtige Hinweise darauf, was das ideale Dateisystem tun muss:

• Massiv zufällige R / W-Zugriffe während des Erstellungsprozesses.
• Viele, viele Dateien werden in kurzer Zeit aktualisiert, daher sind schnelle Metadatenoperationen von entscheidender Bedeutung.
• Effiziente Handhabung vieler kleiner Dateien auf möglicherweise sehr dateilastigen Dateisystemen.
• Ausgereift genug, um in seltenen und undurchsichtigen Randfällen keinen Datenverlust zu riskieren.

Btrfs und Ext4 sind drei der oben genannten, und der vierte ist fraglich. Ext4 ist wahrscheinlich ausgereift genug dafür, aber btrfs ist noch nicht fertig mit Backen. noatimehilft dabei, die Metadatenoperationen effizienter zu gestalten. Wenn Sie jedoch eine Reihe neuer Dateien erstellen, benötigen Sie immer noch Metadatenoperationen, um schreiend schnell zu sein.

Dann wird der zugrunde liegende Speicher zu einem Faktor. XFS-Metadatenoperationen konzentrieren sich in der Regel auf wenige Blöcke, was die Operationen belasten kann. Die Dateisysteme im Ext-Stil sind besser geeignet, die Metadaten näher an die Daten zu bringen, die sie beschreiben. Wenn Ihr Speicher jedoch ausreichend abstrakt ist (Sie laufen in einem VPS oder sind an ein SAN angeschlossen) , spielt dies keine Rolle .

Jedes Dateisystem verfügt über kleine Beschleunigungen, mit denen ein paar Prozentpunkte mehr herausgeholt werden können. Wie leistungsfähig der zugrunde liegende Speicher ist, hat großen Einfluss darauf, wie viel Gewinn Sie sehen werden.

Wenn Sie im Speichersprache genügend Overhead für den E / A-Betrieb in Ihrem Speicher haben, sind Ineffizienzen des Dateisystems weniger wichtig. Wenn Sie eine SSD für Ihre Build-Partition verwenden, ist die Auswahl des Dateisystems weniger wichtig als die, mit der Sie bequemer arbeiten können.

Für viele kleine Dateien würde ich Reiser gegenüber ext3, xfs, jfs ... empfehlen, obwohl ich gehört habe, dass ext4 für dieses Zugriffsmuster viel besser ist (dh das Gegenteil von dem, was Poise sagt) als seine vorherigen Inkarnationen.

Reiser schiebt einen Großteil der Dateistruktur in den Inode-Baum - so funktioniert es sehr gut, wenn es um kleine Dateien geht.

Die Unterschiede im Verhalten zwischen den führenden Dateisystemen sind jedoch relativ gering im Vergleich zu den Vorteilen, die Sie erhalten, wenn Sie über genügend physischen Speicher verfügen, um effektiv zwischenzuspeichern / puffern.

und Scannen von Verzeichnissen, um festzustellen, welche Dateien geändert wurden.

Dies ist ein beschissener Weg, um das Problem zu lösen - obwohl es relativ einfach ist. Wenn es so wichtig ist, denken Sie daran, einen inotify- Handler zu schreiben, um die Mods zu indizieren.

OTOH, wenn Sie eine Flash-SSD verwenden (was zu sehr geringen Suchzeiten führt), würde ich die Verwendung eines fs empfehlen, das das Schreiben aus Gründen der Langlebigkeit effektiver verteilt - z. B. JFFS2