Ich habe lange gedacht, dass es bei Dateisystemen eine richtige Antwort gibt. Eines, das einfach besser ist als die anderen, und wer was anderes nutzt, hat sich schlicht noch nicht richtig informiert. Dann kam der Dezember 2022, und ein Server meines eigenen kleinen Pools fing an, mir etwas anderes beizubringen.
Die Maschine war ein schlichter Backup-Host, eingerichtet mit ext4, weil ext4 eben überall das Standard-Dateisystem von Debian ist. Die Partition lief über Monate stabil, bis ich eines Abends beim Einspielen eines dicken Datenbank-Dumps das Laufwerk vollschrieb. Nicht ein bisschen voll, sondern richtig voll, auf den letzten Block. Ich räumte auf, die Partition war wieder frei, aber das System blieb merkwürdig träge. fsck fand keinen Fehler, SMART sagte alles gut, trotzdem stotterte die Kiste tagelang, bis ich das Dateisystem neu aufbaute. Seitdem frage ich mich bei jedem Storage-Setup nicht mehr, welches Dateisystem die meisten Features hat, sondern welches zu dem Job passt, den die Platte wirklich machen soll.
Dieser Artikel ist mein Versuch, die Dateisystem-Frage für Server ohne Glaubenskrieg zu beantworten. Die drei Kandidaten ext4, XFS und Btrfs sind alle ernst zu nehmende Arbeitstiere. Sie haben unterschiedliche Stärken, unterschiedliche Schwächen und vor allem unterschiedliche Crash-Geschichten. Wer das versteht, wählt nach Workload aus, nicht nach Vorliebe.
Der Rahmen: Worüber reden wir eigentlich?
Alle drei Dateisysteme sind Kernbestandteil des Linux-Kernels, das ist schon mal der wichtigste gemeinsame Nenner. Kein proprietärer Treiber, kein separates Kernel-Modul zum Nachladen, nichts Exotisches. Du formatiert eine Partition mit mkfs und fährst los. Der Unterschied liegt in der Historie und im Design-Ziel.
ext4 ist der Nachfolger von ext3 und damit der direkte Erbe einer Linie, die bis in die frühen 1990er zurückreicht. Es ist seit über zehn Jahren das Standard-Dateisystem von Debian, Ubuntu und den meisten anderen Distributionen. Sein größter Vorteil ist nicht technischer Glanz, sondern schiere Ausgereiftheit: Es gibt kaum einen Fall, der nicht schon tausendmal durchgespielt wurde. XFS stammt ursprünglich von SGI und wurde für große Dateien und hohen Durchsatz auf Workstations und Servern entwickelt, bevor es 2001 in den Linux-Kernel kam. Btrfs ist das jüngste der drei und verfolgt ein anderes Ziel: Es ist kein einfaches Journaling-Dateisystem, sondern versucht, Funktionen zu bündeln, für die man bei den anderen LVM, mdadm und ein Zusatztool braucht.
Ein Satz, den ich Kunden seit Jahren erkläre, fasst es zusammen: ext4 ist der zuverlässige Allrounder, XFS ist der Spezialist für große Daten, Btrfs ist der Schweizer Taschenmesser-Typ, der mehr kann, aber mehr Bedienung braucht. Keines ist pauschal das beste.
Das eigentliche Kriterium: die Workload
Wenn ich heute ein Storage-Setup plane, stelle ich mir genau drei Fragen. Erstens: Wie viele Dateien und wie groß sind sie im Schnitt? Zweitens: Was passiert, wenn der Server mitten im Schreiben abstürzt oder das Laufwerk den Geist aufgibt? Drittens: Welche Funktionen brauche ich wirklich, Snapshots, Checksummen, Kompression, oder reicht ein robustes Journaling?
Der Unterschied zwischen vielen kleinen und wenigen großen Dateien ist der größte Hebel. Ein Webserver mit tausenden kleinen PHP-, Log- und Cache-Dateien hat ein anderes Profil als ein Archiv-Server, auf dem 40-GB-ISO-Images und Backup-Bänder liegen. Die einen brauchen effiziente Metadaten-Verwaltung für zehntausende Einträge, die anderen müssen große Blöcke mit möglichst wenig Overhead sequenziell schreiben und lesen. Wer diese beiden Profile verwechselt, wählt das falsche Dateisystem.
ext4: der zuverlässige Allrounder
ext4 ist meine Standardantwort für alles, bei dem ich mir nicht sicher bin. Es ist das Dateisystem, das auf Servern am häufigsten läuft, das beste Tooling hat und dessen Verhalten nach einem Crash am berechenbarsten ist. Die 2008er-Revision brachte drei wichtige Neuerungen: Extents statt der alten Block-Mapping-Struktur, was die Verwaltung großer Dateien verbessert, verzögertes Allocation und ein Journaling, das Standard geworden ist.
Für den Serverbetrieb sind zwei Eigenschaften besonders wertvoll. Erstens die Robustheit nach einem Absturz: ext4 journallt standardmäßig die Metadaten, das heißt, die Struktur des Dateisystems bleibt nach einem harten Reboot konsistent, auch wenn einzelne Datenblöcke verloren gehen können. Zweitens das Tooling: e2fsck ist das mit Abstand am ausgereifteste Reparaturwerkzeug der drei, und nach zwanzig Jahren ext4-Nutzung habe ich nur selten einen Fall gesehen, den e2fsck nicht lösen konnte.
Die Grenzen sind ebenso klar. Ein Dateisystem kann online vergrößert werden, aber nicht verkleinert, das geht nur offline. Snapshots gibt es nicht nativ, dafür brauchst du LVM, was in meinen Setups ohnehin oft schon darunterliegt. Und es prüft keine Daten-Checksummen, ein stiller Bit-Rot wird also nicht erkannt. Für Datenbanken, Webserver und den klassischen LAMP-Stack ist das alles kein Problem.
Ein Detail, das viele unterschätzen: die IOPS. Wer viele kleine Dateien schreibt, limitiert schnell die I/O-Operationen pro Sekunde, nicht den Durchsatz. Genau dafür gibt es auf bitcalc einen IOPS-Rechner, mit dem sich ausrechnen lässt, wie viele Operationen eine geplante Arbeitslast braucht und ob die Platte das schafft. Beim Planen von ext4-Partitionen für Webserver nutze ich das regelmäßig.
XFS: der Spezialist für große Daten
XFS wurde von SGI für Hochleistungs-Server entwickelt und trägt diese DNA bis heute. Sein Design zielt auf hohen Durchsatz mit großen Dateien und parallelen Schreibzugriffen ab. Dafür verwendet es eine Allokationsstrategie, die auf viele Dateien und kleine Blöcke nicht optimal ist. Das Ergebnis: XFS ist auf Archiven, Backups, Video-Dateien und großen VM-Images glänzend, auf einem Verzeichnisbaum mit hunderttausend kleinen Dateien dagegen spürbar schwächer als ext4.
Was XFS technisch auszeichnet, ist die Skalierung. Die Maximalwerte sind schwindelerregend: Dateigrößen bis 8 EiB und Dateisysteme in ähnlicher Größenordnung, Zahlen, die für reale Server praktisch nie erreichbar sind. Praktisch wichtiger ist die verzögerte Allokation und das effiziente Handling sehr großer, kontinuierlicher Bereiche. Beim sequenziellen Schreiben eines 100-GB-Backups ist XFS deutlich im Vorteil.
Die Kehrseite bei Crashs kenne ich aus eigener Erfahrung: xfs_repair funktioniert, aber es läuft komplett im RAM, und bei sehr großen Dateisystemen kann ein Reparaturlauf Stunden dauern und viel Arbeitsspeicher fressen. Bei meinem Archiv-Server achte ich deshalb darauf, dass das XFS-Dateisystem sauber unmountet wird, bevor der Server heruntergefahren wird. Ein hartes Abschalten eines beschriebenen XFS ist der Klassiker, der zu einem langen Repair führt.
Für die Praxis heißt das: XFS ist mein Favorit für alles, was in wenigen, großen Dateien denkt, also Backup-Ziele, Medien-Archive und Storage-Pools für virtuelle Maschinen. Wer große Dateien schreibt und viele davon gleichzeitig lesen lässt, bekommt hier den besten Durchsatz.
Btrfs: der Alleskönner mit Anleitung
Btrfs ist das ambitionierteste der drei und dasjenige, über das die hitzigsten Debatten geführt werden. Es bringt Funktionen mit, die bei ext4 und XFS gar nicht erst auf dem Schirm sind: Copy-on-Write mit Snapshots, Checksummen für Daten und Metadaten, Kompression, Subvolumes und eine eigene RAID-Implementierung. Kein anderes der drei kann das nativ aus einer Hand.
Die Snapshots sind der Killer-Feature. Ein Snapshot ist eine fast kostenlose Momentaufnahme eines Subvolumes, mit der du nach einem versehentlichen rm -rf oder einer kaputten Aktualisierung in Sekunden zurückrollen kannst. Dazu kommen Checksummen: Btrfs erkennt stille Datenfehler, also Bit-Rot auf der Platte, und kann bei einem RAID-1- oder RAID-10-Setup sogar selbst heilen. Genau diese Eigenschaften machen Btrfs für Home-Verzeichnisse und Verzeichnis-Server so attraktiv.
Aber Btrfs ist kein Werkzeug für Anfänger. Es braucht Pflege: Snapshots füllen irgendwann das Laufwerk, wenn man sie nicht regelmäßig aufräumt, und die eigene RAID-Implementierung, vor allem RAID 5 und RAID 6, hatte lange einen schlechten Ruf wegen Datenverlust-Bugs. In meinen Setups nutze ich Btrfs deshalb dort, wo seine Stärken wirklich greifen, und halte es von den Orten fern, an denen sein Copy-on-Write stört.
Ein klassisches Missverständnis: Copy-on-Write ist nicht überall ein Segen. Wenn eine Datenbank ihre eigenen Datenblöcke immer wieder überschreibt, führt CoW zu Fragmentierung und deutlich mehr Schreibaufwand, weil jede Änderung einen neuen Block erzeugt. Deshalb deaktiviere ich CoW für Datenbank-Dateien und VM-Images auf Btrfs explizit mit chattr +C. Ohne dieses Detail wäre mein Btrfs-Experiment früh gescheitert.
Was ich nach einem echten Crash gelernt habe
Zurück zu meinem Backup-Host vom Anfang. Die Lehre aus dem Dezember 2022 war nicht, dass ext4 schlecht ist, sondern dass ich das falsche Dateisystem für den Job gewählt hatte. Ein Backup-Ziel, das hauptsächlich große, sequenziell geschriebene Dateien aufnimmt, ist genau das Profil, für das XFS gebaut wurde. Die ext4-Partition hatte mit der Last im Prinzip kein Problem, aber als ich sie vollschrieb und wieder befreite, zeigte sich, wie stark die Fragmentierung auf einem vollgelaufenen ext4 sein kann.
Seitdem läuft auf dem Backup-Host XFS, und die Maschine macht keine Probleme mehr. Der Datenbank-Dump, der damals das Laufwerk vollschrieb, landet heute in einem XFS-Dateisystem, und der Full-Disk-Zustand ist nur noch ein Fall für den Monitoring-Alarm, nicht für ein träges System danach.
Die zweite Geschichte betrifft Btrfs und ist erfreulicher. Auf einem meiner Entwicklungs-Server stand ein Verzeichnis-Server mit Btrfs. Ein Kollege löschte beim Aufräumen versehentlich einen ganzen Home-Ordner mit zwei Jahren Daten. Weil ich auf dem Subvolume alle sechs Stunden einen Snapshot fahren lasse, war der Ordner nach einem einzigen cp aus dem Snapshot wieder da, inklusive aller Dateien. Das Dateisystem hat an dem Tag einen Fehler gerettet, den kein Backup-Plan abgedeckt hätte, weil er nicht vorhersehbar war.
Feature-Matrix: die drei im direkten Vergleich
Die Tabelle zeigt das Wichtigste auf einen Blick. Auffällig ist das Muster: XFS ist dort stark, wo ext4 nur gut ist, nämlich bei großen Dateien und Durchsatz. Btrfs glänzt bei Snapshots und Checksummen, wo die anderen beiden schlicht nichts bieten. Und ext4 hält sich überall gut, ohne irgendwo den absoluten Bestwert zu erreichen. Genau dieses Profil macht es zum Default.
Zwei Zeilen verdienen besondere Aufmerksamkeit. Die erste ist Online-Verkleinern: ext4 kann das nicht im laufenden Betrieb, XFS auch nicht, Btrfs schon. Klingt nach einem Detail, ist aber für flexible Storage-Nutzung relevant. Die zweite ist Daten-Prüfsummen: nur Btrfs erkennt stille Datenfehler. Wer lange Archive ohne RAID betreibt und Bit-Rot fürchtet, findet hier einen echten Unterschied.
Die Empfehlung je Einsatzprofil
Aus der Matrix und meinen Crash-Erfahrungen ergibt sich eine ziemlich klare Zuordnung, die ich in der Praxis seit Jahren so umsetze.
Für einen Webserver mit vielen kleinen Dateien nehme ich ext4. Die Metadaten-Verwaltung ist für zehntausende kleine Dateien effizient, das Tooling robust, und die wenigen Features, die fehlen, braucht ein klassischer LAMP-Stack nicht. Dasselbe gilt für Datenbank-Server: MySQL und PostgreSQL schreiben kleine Blöcke ständig neu, und da ist ext4 mit seinem vorhersehbaren Verhalten die sichere Wahl. Ich würde auf einem Datenbank-Server nur in Ausnahmefällen XFS nehmen und nie Btrfs ohne CoW-Deklaration.
Für Backup-Ziele, Medien-Archive und Storage für virtuelle Maschinen nehme ich XFS. Dort liegen große Dateien, die sequenziell geschrieben werden, und XFS liefert dafür den besten Durchsatz und die beste Skalierung. VM-Images und große ISO-Archive sind das Paradebeispiel. Der Preis, ein komplexerer Repair nach einem harten Crash, ist bei sauber gemanagten Servern selten fällig.
Für Home-Verzeichnisse und Verzeichnis-Server mit vielen Benutzern nehme ich Btrfs. Die Snapshots sind Gold wert, wenn jemand versehentlich etwas löscht oder eine Aktualisierung schiefgeht, und die Checksummen schützen vor stillen Datenfehlern. Btrfs ist hier mein Werkzeug, weil genau die Funktionen gebraucht werden, die es als einziges der drei hat. Vorausgesetzt, ich räume die Snapshots regelmäßig auf und prüfe die Laufwerksauslastung.
Die ehrliche Warnung: Dateisysteme sind kein Ersatz für Backups
Ein Satz, den ich nicht oft genug wiederholen kann: Kein Dateisystem, nicht einmal Btrfs mit seinen Checksummen und Snapshots, ersetzt ein Backup. Snapshots liegen auf derselben Platte wie die Daten. Wenn die Platte stirbt, das RAID auseinanderfällt oder der Server gestohlen wird, sind auch alle Snapshots weg.
Checksummen erkennen stille Fehler, aber sie reparieren nichts, ohne eine zweite Kopie. Ein RAID-1 mit Btrfs kann heilen, weil es die gute Kopie hat, aber ohne redundante Kopie bleibt ein erkanntes Problem nur ein gemeldetes Problem. Und wer Backups auf derselben Maschine liegen hat wie die Originaldaten, hat im Ernstfall gar keine Backups. Die 3-2-1-Regel gilt unabhängig vom Dateisystem.
Das bedeutet für die Praxis: Wähle das Dateisystem nach der Workload, aber plane Backups so, als wäre das Dateisystem nur ein Detail. Auf einem guten Setup läuft die richtige Kombination aus Dateisystem, RAID und Backup-System zusammen, und keins davon ersetzt die anderen.
Dateisystemwahl ist eine Entscheidung, kein Bekenntnis
Was ich aus fast zwei Jahrzehnten Serverbetrieb mitgenommen habe, passt in drei Regeln. Erstens: Entscheide nach der Workload, nicht nach dem Bauchgefühl. Zweitens: Sei bereit, eine Entscheidung zu revidieren, wenn die Realität es zeigt, mein Backup-Host ist das beste Beispiel. Drittens: Teste das Crash-Verhalten, bevor du es im Ernstfall brauchst, ein geplanter harter Reboot mit anschließendem fsck sagt mehr als jede Spec.
ext4 ist mein Default, weil es selten falsch ist. XFS ist mein Werkzeug für große Daten, weil es dafür am schnellsten ist. Btrfs ist mein Werkzeug für Verzeichnisse, weil es Snapshots und Checksummen mitbringt. Keines davon ist das beste Dateisystem, sie sind nur jeweils das richtige für eine bestimmte Aufgabe. Wer das versteht, hat den Dateisystem-Glaubenskrieg für sich beendet.
Und wenn du vor einer Storage-Planung stehst, rechne zuerst nach, welche I/O-Last wirklich auf der Platte landet. Der bitcalc IOPS-Rechner hilft dabei, aus Anwendungszahlen und Plattenwerten eine realistische Anforderung zu machen, bevor du das Dateisystem überhaupt wählst.