7.1. Welches Dateisystem soll ich verwenden?

7.1.1

In Suse Linux 8.2 und höher werden die folgenden "interessanten" Dateisysteme unterstützt:

• reiserfs (Der Default bei der Installation)
• ext2
• ext3
• xfs
• jfs

Transaktionen und Logs

Bis auf ext2 sind dies alles transaktionsorientierte Dateisysteme. Das bedeutet, daß nach einem ungeordneten Systemstop (einem Crash) das Dateisystem oft mit Hilfe des Logs wieder geordnet werden kann. Die Zeit zur Systemwiederherstellung ist in diesem Fall also nicht davon abhängig, wie groß die Platte ist, sondern nur, wie viele Transaktionen im Log stehen (wie viele Dateioperationen zum Zeit des Absturzes offen waren).

Transaktionsorientierte Dateisysteme bezahlen diesen Vorteil mit dem Nachteil des erhöhten Platzverbrauches (Das Log verkleinert ein Dateisystem um eine gewisse Größe, oft etwa 32MB). Für sehr kleine Dateisysteme, bei denen ein traditioneller fsck sehr schnell geht, ist es also vorteilhaft, ein Dateisystem ohne Log, etwa ext2 zu nehmen.

Ab einer Größe von einem GB aufwärts lohnt sich ein transaktionsorientiertes Dateisystem, weil hier der Größenverlust durch das Log nicht ins Gewicht fällt und weil hier die Checkzeiten durch den fsck meßbar werden.

Verzeichnisse als Bäume vs. Verzeichnisse als lineare Listen

Von reiserfs und xfs weiß ich, daß sie Verzeichnisse als Baumstrukturen und nicht wie traditionelle Dateisysteme (ext2, ext3) als lineare Listen anlegen. Daher können reiserfs und xfs große Verzeichnisse (10000 und mehr Dateien in einem Verzeichnis) effizient bearbeiten.

Traditionelle Dateisysteme werden in solchen Strukturen sehr langsam, weil sie beachtliche Zeit zum linearen Durchsuchen der Verzeichnisstrukturen aufbringen müssen. Anwendungen wie ein INN Newsserver mit Tradspool, ein Squid Webcache und sehr große Cyrus Mailfolder oder sehr große kmail Maildirs profitieren sehr stark von den verbesserten Datenstrukturen eines reiserfs oder xfs.

Access Control Lists und Extended Attributes

In SUSE-Linux sind die notwendigen Patches für reiserfs, ext3 und ext2 enthalten, so daß auch diese Dateisysteme mit ACLs und EAs umgehen können. xfs und jfs konnten dies wegen ihrer Herkunft von kommerziellen Unices (xfs von IRIX (SGI) bzw. jfs von AIX (IBM)) schon lange bevor sie auf Linux portiert wurden.

Umgang mit großen Dateien und großen UIDs

Von reiserfs weiß ich durch selbst ausprobieren, daß (in reiserfs 3.6, nicht jedoch in 3.5) Dateien mit mehr als 4 GB Dateigröße angelegt und verwaltet werden können. Ich weiß auch, daß dieses Dateisystem mit UIDs > 16 Bit umgehen kann, also User- und Gruppennummern über 65536 korrekt verwalten kann.

Von XFS weiß ich, dass dies bei diesem Dateisystem ein Designkriterium war.

Voraussetzung für die Nutzung dieser Eigenschaften ist, daß die libc ausreichend neu ist (>= 2.1) und ebenfalls mit großen Dateien und mit großen UIDs umgehen kann. Dies ist bei Suse Linux 8.2 und 9.0 getestetermaßen der Fall (und vermutlich schon seit SuSE-Linux 6.4).

Stabilität

Das älteste und am einfachsten strukturierte Dateisystem in der Distribution (das sich sinnvoll auf auch nur halbwegs modernen Festplatten verwenden lässt) ist ext2. Es besteht im Kernel aus kaum 5000 Zeilen Code (plus ca. 50.000 Zeilen Userland-Supportcode in mkfs, fsck und anderen Hilfsutilities). Dieser Code ist recht gut untersucht, und mittlerweile auch von einigermaßen guter Qualität (Das war zu den Zeiten, als ich meine Diplomarbeit über Invarianten in ext2 schrieb, noch nicht der Fall).

In Suse Linux ist reiserfs ebenfalls recht gut getestet: Suse Linux verwendet reiserfs schon seit Jahren als Default-Dateisystem, Suse finanziert die Weiterentwicklung von reiserfs substantiell mit und ich nehme an, daß Suse auch interne Supportcalls an das Reiser-Team weiterleitet, sodaß sowohl Suse als das Reiser-Team recht gute Vorstellungen davon haben sollten, wie Reiser und Suse-Kernel zusammenspielen.

Der Code in XFS und JFS ist ebenfalls recht alt (mehr als zehn Jahre) und in zahlreichen kommerziellen Deployments getestet. Speziell XFS ist dabei ab Start dafür designed worden, besonders in großen Dateisystemen sinnvoll zu skalieren - die XFS-Designer haben dabei schon 1994 (! damals waren noch Festplatten von < 500 MB "State of the Art") an Multi-Terabyte Dateisysteme mit Dutzenden von konkurrierenden Readern und Writern gedacht. Das merkt man dem internen Design von XFS auch an. Zum Vergleich: Der kernel-interne Code von XFS ist etwa 10-20 mal umfangreicher und komplexer als der Code von ext2.

XFS und JFS sind beide nicht in Linux entstanden, sondern als Bestandteil von SGI Irix (xfs) und AIX (jfs). Sie sind danach nach Linux und die deutlich unterschiedlichen Kernel-Schnittstellen von Linux portiert worden. Ich habe keine Idee, wie stark man das dem Code noch anmerkt oder wie sehr das Stabilität und Effizienz belastet.

Persönliche Anekdoten über Stabilität

Ich habe jahrelang ext2 als Default-Dateisystem verwendet und damit SCSI- und IDE-Platten bis in den zweistelligen GB-Bereich hinein benutzt. Darunter waren auch einige stark belastete Server mit sehr unterschiedlichen Dateigrößen und Benutzungsanforderungen (Newsserver, File+Print-Server, MP3-Server et al). ext2 ist simpel und hat auf diesen Kisten gut Dienst getan. Der fsck von ext2 ist primitiv, aber relativ komplett und sehr zuverlässig. Ich hatte Gelegenheit, ihn im Rahmen meiner Diplomarbeit ausgiebig zu studieren und formal zu analysieren und auch dort hat er überwiegend einen guten Eindruck gemacht.

Gegenüber reiserfs und xfs haben ext2 und ext3 beim fsck den Vorteil, daß sie schon beim Anlegen des Dateisystems festlegen (müssen), welche Blöcke Daten und welche Blöcke Metadaten enthalten. Der fsck von ext2 und ext3 kann also schon an der Blocknummer erkennen, ob es sich um eine Inode, Daten oder sonst einen Bestandteil des Dateisystems handelt.

reiserfs und xfs können dies nicht. Ist die Datenstruktur des Dateisystems noch rettbar ("reiserfsck --fix-fixable"), macht das keinen Unterschied, weil der fsck dann aus dem Dateibaum ableiten kann, was Daten und was Metadaten sind. Ist der Metadatenbaum jedoch komplett im Eimer ("reiserfsck --rebuild-tree"), dann muß der fsck hier das ganze Dateisystem durchscannen und kann dann auf der Grundlage von Magic Numbers in den Datenstrukturen vielleicht erkennen, ob es sich um Daten oder Metadaten handelt.

Das führt zu interessanten Effekten, wenn sich auf dem zu untersuchenden Dateisystemen weitere Reiserfs-Datenstrukturen in loop-Dateien, vmware-vmdk-Dateien oder anderen Containern befinden. In meinem Fall hat so ein Scan ca. 800 MB Geisterfiles in die neue Root des geretteten reiserfs gebeamt (Nutzdaten sind jedoch nicht verloren gegangen, und der ursprüngliche Crash ging auf das Konto vom nvidia-Treiber, nicht von reiserfs).

Entscheidungskriterien

Suse Linux verwendet per Default reiserfs. Das ist eine gute und inzwischen stabile Wahl. Neulinge und unerfahrene Benutzer sollten dies einfach so lassen und den Installer machen lassen.

Performance-Junkies und Benutzer sehr großer Dateisysteme (wir reden hier von Terabytes im Plural) oder vieler großer Dateien sollten sich einmal XFS ansehen (Video-Server z.B.). Es hat eine Reihe von Features, die diesen Anwendern sehr entgegen kommen.

ext2 und ext3 sind eher konservative Dateisysteme. Sie haben Performanceprobleme mit großen Dateisystemen, mit großen Verzeichnissen und mit großen Dateien mit vielen konkurrenten Writern (etwa großen Oracle DBF-Dateien). Sie sind andererseits sehr gut untersucht und verstanden und sie haben Datenstrukturen auf der Platte mit passiver Sicherheit. ext2 ist außerdem sehr klein. Benutzer leistungsschwacher PCs mit kleinen Platten sollten ext2 oder ext3 verwenden. Benutzer existierender ext2-Dateisysteme, die nicht neu formatieren wollen, sollten ihre ext2-Installation auf ext3 upgraden, wenn das existierende Dateisystem wenigstens ein GB groß ist, und so wenigstens die Vorteile des Loggings nutzen.

Benutzer mit großen Directories (mehr als 10000 Files in einem Verzeichnis) sollten ein Dateisystem mit Baumstrukturen als Verzeichnisse verwenden, etwa reiserfs oder xfs.