Linux-Dateisysteme im Vergleich: ext4, XFS, Btrfs, ZFS, bcachefs, exFAT, NTFS – und NFS, CephFS, GlusterFS

Zwei Welten, die man nicht vergleichen kann

In der Frage steckt eine Kategorie-Verwechslung: ext4, XFS, Btrfs, bcachefs, ZFS, JFS, exFAT und NTFS sind lokale Dateisysteme — sie verwalten Blöcke auf einer Platte. NFS, CephFS und GlusterFS sind Netzwerkdateisysteme: Sie setzen auf einem lokalen Dateisystem auf und verteilen es über ein Netz. Man wählt sie nicht statt ext4, sondern zusätzlich.

Praktisch heißt das: Die Netzwerkseite bringt eigene Fragen mit — Rechte, Sperren, Ausfälle, Latenz — und die drei Kandidaten dort unterscheiden sich untereinander deutlich stärker als ext4 von XFS.

Die Kriterien, an denen man wirklich vergleicht

Zehn Eigenschaften entscheiden in der Praxis, und keine davon heißt „schnell“.

Zwei Kriterien, die in Foren gern dominieren, fehlen bewusst: maximale Dateigröße und Maximaldurchsatz. Die Grenzen liegen im Zwei- bis Acht-EiB-Bereich und damit weit jenseits dessen, was ein Heim- oder Rootserver berührt. Und der Durchsatz wird in der Praxis von Platte, Controller, RAM und Last bestimmt — nicht vom Dateisystem.

Mein Messaufbau

Für die Tabelle unten habe ich auf einem CachyOS-System jeweils ein 512-MiB-Image angelegt und mit den Standardwerten formatiert — kein Tuning, keine mount-Optionen, kein Betrieb. Anschließend habe ich die Metadaten ausgelesen (dumpe2fs, xfs_db, btrfs inspect-internal dump-super, jfs_tune, dump.exfat, fsck.fat).

Drei Kandidaten konnte ich hier nicht messen, weil die Werkzeuge fehlen — das ist selbst ein Ergebnis: ZFS (kein zpool), bcachefs (kein mkfs.bcachefs) und NTFS (kein mkfs.ntfs). Deren Abschnitte sind beschreibend, mit den Fallstricken, die man kennen muss.

Gemessene Standardwerte

512-MiB-Image, Standardwerte, keine mount-Optionen:

Was man daran ablesen kann:

• Btrfs legt praktisch nichts fest. 160 KiB Metadaten, keine Inode-Tabelle, keine Journaldatei — es wächst mit dem Bedarf. Das ist der Grund, warum frisch formatierte Btrfs-Platten „mehr Platz“ zu haben scheinen als ext4-Platten.
• XFS reserviert 64 MiB für sein internes Log — bei einer kleinen Platte spürbar, auf einem 2-TB-Volume unsichtbar. XFS legt außerdem nur 64 Inodes an und erzeugt weitere dynamisch: für Verzeichnisse mit Millionen kleiner Dateien ist das der entscheidende Vorteil gegenüber ext4.
• ext4 legt seine Inode-Tabelle beim Formatieren fest. 32768 bei 512 MiB — wer sich verschätzt, hat später entweder zu wenige Inodes (ENOSPC trotz freiem Platz) oder ungenutzten Platz. Mit mkfs.ext4 -i, -N oder -T small lässt sich das steuern.
• exFAT wählt die Clustergröße nach der Volume-Größe — bei 512 MiB sind das bereits 32 KiB. Eine 500-Byte-Datei belegt damit 32 KiB. Für Kamerakarten ideal, für Quellcode eine Platzverschwendung.
• FAT32 und exFAT haben kein Journal. Beide sind für den Austausch gedacht, nicht für Daten, die einen Stromausfall überleben sollen.

ext4: der Verlässliche

ext4 ist die vierte Generation der ext-Reihe und seit 2008 der Standard fast jeder Linux-Distribution. Es ist das Dateisystem, das niemand vorführt und das trotzdem die meisten Server betreiben.

Stärken: überall verfügbar, vorhersagbar, online vergrößerbar, offline verkleinerbar, breites Werkzeugangebot, lange erprobte Fehlerpfade. Schwächen: feste Inode-Tabelle (gemessen: 32768 bei 512 MiB), keine Datenprüfsummen, keine Snapshots, keine Reflinks, unter dichten Schreibvorgängen wie Datenbanken mittelmäßig. Und fsck kann bei Terabyte-Volumes Stunden dauern.

Praxis-Tipps: Die 5 % reservierten Blöcke für root sind heute meist zu viel — tune2fs -m 1 /dev/sdX gibt Platz frei. noatime spart Schreibzugriffe. Für System-, Boot- und /var-Partitionen gibt es weiterhin kaum einen Grund, etwas anderes zu nehmen.

XFS: der Parallel-Arbeiter

XFS wurde bei SGI für Maschinen mit vielen Kernen, vielen Platten und großen Dateien entwickelt. Es unterteilt das Volume in Allocation Groups, die parallel beschrieben werden können — der Grund, warum XFS auf heutigen NVMe-Systemen unter paralleler Last oft vorn liegt.

Stärken: hervorragende Parallelität, dynamische Inodes (gemessen: nur 64 vorbelegt), sehr große Volumes und Dateien, Online-Vergrößerung, Reflinks und Dedup, exzellente Werkzeuge (xfs_growfs, xfs_repair, xfs_db, xfs_metadump). Schwächen: Volumes lassen sich nicht verkleinern, es gibt keine Prüfsummen für Nutzdaten, keine Snapshots auf Dateisystemebene, und beschädigte Metadaten können eine Reparatur verlangen, die Zeit braucht. Mit dem internen Log von 64 MiB (gemessen) ist XFS auf winzigen Volumes unnötig teuer.

Btrfs: der Alleskönner mit Eigenheiten

Btrfs ist das Standarddateisystem von openSUSE, Fedora und CachyOS. Es bringt, was ext4 nicht hat: Copy-on-Write, Subvolumes, Snapshots, Prüfsummen für Daten und Metadaten, transparente Kompression, Reflinks und Mehrgeräte-Unterstützung.

Stärken: Snapshots in Sekunden, btrfs send/receive für inkrementelle Backups, Subvolumes ohne Größenfestlegung, Kompression im Betrieb, Reflinks für sofortige Kopien, Selbstheilung im RAID1-Verbund. Schwächen: RAID5/6 gilt wegen der Write-Hole-Problematik nicht als produktionsreif; stark fragmentierte Dateien brauchen gelegentlich Pflege; das Platzverhalten ist gewöhnungsbedürftig; und ein fast volles Volume kann in unangenehme Zustände laufen.

Dass Kompression im Betrieb wirklich trägt, habe ich auf demselben System gemessen: 239 MiB Textdatei → 9 MiB belegt (Faktor 26, Mount-Option compress=zstd:3).

bcachefs: der junge Herausforderer

bcachefs wollte das Beste aller Welten in einem Dateisystem vereinen: Copy-on-Write, Prüfsummen, Kompression, Verschlüsselung, Mehrgeräte-RAID, Cache-Stufen, Snapshots und Subvolumes — im Kernel, nicht als Zusatzmodul. Seit Kernel 6.7 gehört es zum Hauptzweig.

Stärken: ein einziges Werkzeug für Aufgaben, für die man sonst ZFS plus LUKS plus RAID kombiniert; modernes Design ohne jahrzehntelange Altlasten; das Format gilt als stabil und soll weiterentwickelbar sein. Schwächen: Es ist jung. Die Werkzeuge müssen zur Kernel-Version passen, es gibt deutlich weniger Erfahrungswerte, weniger Dokumentation und weniger Rettungsgeschichten — und genau die sind bei Dateisystemen das eigentliche Kriterium. Bei mir fehlte schon mkfs.bcachefs: Die Werkzeuge sind nicht in jeder Distribution dabei.

ZFS: der Goldstandard für Datenintegrität

ZFS stammt von Sun und wurde für einen Satz von Problemen entworfen, die man damals mit RAID-Controllern und fsck löste — nur besser: Ein Pool vereint Platten, RAIDZ ersetzt RAID5/6, jede Datenkopie hat eine Prüfsumme, Snapshots sind praktisch kostenlos, und send/receive macht daraus ein Backup-System.

Stärken: Prüfsummen für alles, Selbstheilung im Verbund, Datenkompression, Dedup (mit Vorsicht), native Verschlüsselung, Quotas und Datasets, bewährt seit rund zwanzig Jahren, exzellente Werkzeuge und ungewöhnlich gute Dokumentation. Schwächen: ZFS wird nicht im Linux-Hauptzweig gepflegt (Lizenz CDDL), sondern als Modul nachgeliefert — auf meinem System fehlte es komplett (zpool nicht vorhanden). Es ist speicherhungrig: Der ARC-Cache nutzt RAM, und Dedup bricht ohne ausreichend RAM ein. Vdev-Layouts sind eine Einbahnstraße: Wer eine RAIDZ-Konfiguration nachträglich ändern will, baut neu auf. Auf einer 1-GB-VM ist ZFS die falsche Wahl.

JFS: der Vergessene

JFS ist IBMs Journaled File System — seit Linux 2.4 dabei. Es war lange die schlanke Alternative: geringe CPU-Last, Inline-Log (also kein separates Log-Gerät nötig, in jfs_tune als JFS_INLINELOG sichtbar), dynamische Inodes, 4-KiB-Blöcke.

Stärken: genügsam bei CPU und Speicher, stabil, unaufgeregt. Schwächen: Es hat sich nicht weiterentwickelt — die Werkzeuge stammen in Teilen aus den 2010er Jahren, es gibt keine Prüfsummen, keine Snapshots, keine Kompression, kein Mehrgeräte-Betrieb. Wenn etwas schiefgeht, ist die Rettungsgemeinschaft klein. Damit ist es das, was man heute am ehrlichsten so beschreibt: funktioniert, aber niemand braucht es neu.

exFAT: der Austauschstandard

exFAT ist kein Linux-Dateisystem, sondern ein Standard für Wechselmedien: von Kameras, Fernsehern, Autoradios, Windows, macOS und Linux gleichermaßen gelesen. Es kennt keine Rechte, keine Besitzer, keine symbolischen Links, kein Journal — und keine 4-GiB-Grenze, die FAT32 plagt.

Stärken: universelle Kompatibilität, große Dateien möglich, sparsame Metadaten. Schwächen: kein Journaling, also kein Schutz vor unsauberem Aus- und Einstecken; keine Rechte oder Link-Metadaten, damit ungeeignet für Systemverzeichnisse, /home, Git-Repos und alles, was mit Berechtigungen arbeitet; und die gemessene Clustergröße von 32 KiB bei 512 MiB Volume verschwendet bei vielen kleinen Dateien viel Platz.

NTFS: für die Windows-Welt

NTFS ist das Windows-Dateisystem: Journal, feinkörnige Rechte (ACLs), Kompression, Verschlüsselung, Sparse Files, Hardlinks. Linux liest und schreibt es über zwei Wege: den ntfs3-Treiber im Kernel (vorhanden und aktiv, wie in /proc/filesystems sichtbar) oder ntfs-3g über FUSE (kompatibler, langsamer, auf meinem System nicht installiert).

Stärken: wenn eine Platte an Windows und Linux gehen soll, ist NTFS oft die bessere Wahl als exFAT — sobald Windows-Rechte oder Dateien über 4 GiB eine Rolle spielen. Schwächen: Es ist kein POSIX-Dateisystem. Besitzer und Rechte werden beim Mounten zugewiesen (uid, gid, umask), nicht gespeichert; Symlinks und Sonderdateien funktionieren nur eingeschränkt; Nutzdatenprüfsummen fehlen.

Netzwerkdateisysteme im Vergleich

Jetzt die andere Kategorie. Alle drei machen Verzeichnisse über das Netz verfügbar. Der entscheidende Unterschied liegt darin, wer die Verteilung organisiert und wie viel Betrieb sie verlangt.

NFS: der Standard im LAN

NFS ist der Klassiker: Der Server exportiert ein Verzeichnis in /etc/exports, der Client bindet es ein — seit Version 4 über einen Port (2049), mit ACLs, optional mit Kerberos. nfs-utils ist auf meinem System installiert.

Stärken: jahrzehntelang erprobt, in jedem Linux und jeder NAS-Box, transparent für Anwendungen, wartungsarm. Schwächen: Es ist synchron — die Latenz des Netzes schlägt auf jede Dateioperation durch. Bei WLAN ist das spürbar, über WAN ohne VPN gefährlich. Ein hängender Server kann Clients blockieren. Und Redundanz hat NFS selbst nicht: Das ist Aufgabe des Servers darunter.

CephFS: Skalierung mit Betriebsaufwand

Ceph ist ein verteiltes Speichersystem, das drei Dinge aus einem Baukasten liefert: Objektspeicher (S3-kompatibel), Blockspeicher (für virtuelle Maschinen) und ein Dateisystem (CephFS). Daten werden über OSDs verteilt, der Cluster kennt den Zustand über Monitore, und der Metadata-Server hält die Verzeichnisstruktur.

Stärken: echte Skalierung von drei auf tausende Knoten, Selbstheilung, regelbasierte Datenverteilung, POSIX-Semantik, Snapshots und Quotas. Schwächen: der Aufwand. Selbst ein Testcluster braucht Monitore, OSDs und einen MDS — unter drei Maschinen ergibt das keinen Sinn, und wer Ceph betreibt, betreibt einen kleinen Storage-Cluster mit eigener Fehlerkultur. Für den Heimserver mit einer Platte ist Ceph die Antwort auf eine Frage, die niemand gestellt hat.

GlusterFS: einfach verteilt, zuletzt still

GlusterFS war die einfache Antwort auf verteilten Speicher: Bricks auf mehreren Servern, ein gemeinsames Volume, keine zentrale Metadaten-Instanz, Redundanz wahlweise über Replikation oder Erasure Coding. Zwei Rechner, ein repliziertes Volume — Ausfallsicherheit ohne Cluster-Zeremonie.

Stärken: einfacher Einstieg, keine Metadaten-Instanz (kein Single Point of Failure), flexible Volume-Typen, gut für Ablagen mit großen Dateien. Schwächen: Das Projekt hat spürbar an Dynamik verloren — Red Hats Storage-Strategie dreht sich um Ceph, und neue Einsatzberichte werden selten. Damit fehlt genau das, was man bei verteilten Dateisystemen braucht: eine wachsende Erfahrungsbasis. Bei kleinen Dateien gab es weiterhin Performance-Schwierigkeiten.

Entscheidungshilfe

Was für alle gilt

• Ein Dateisystem ersetzt kein Backup. Prüfsummen und Snapshots schützen vor Bitfehlern und Bedienfehlern — nicht vor Blitzschlag, Diebstahl oder einem versehentlich gelöschten Snapshot. Kopien bleiben Kopien, egal wie modern das Dateisystem ist.
• Mount-Optionen wirken stärker als die Dateisystemwahl. noatime spart Schreibzugriffe, discard=async oder fstrim halten SSDs in Form, commit=120 verringert Schreiblast. Das sind Prozentpunkte — die Wahl zwischen ext4 und XFS ist in vielen Setups dagegen Geschmack.
• Fremde Benchmarks sagen nichts über deine Last. Dateigröße, Anzahl der Dateien, Nebenläufigkeit, Verschlüsselung und Kompression verändern das Ergebnis stärker als das Dateisystem. Wer es genau wissen will, testet mit fio gegen die eigene Platte.
• Reparatur dauert — und muss eingeplant werden. fsck über ein Terabyte-Volume braucht Stunden, xfs_repair kann über Nacht laufen, bei ZFS ist scrub Pflichtprogramm. Ein Wartungsfenster ist günstiger als eine Notfallrunde.
• Vorsicht bei zu vollen Volumes. Alle Dateisysteme werden über 90 % Füllstand langsam; Btrfs und ZFS können dort in Zustände laufen, in denen Aufräumen mühsam ist. Wenn die Platte „nur noch ein bisschen“ Platz hat, ist das der Zeitpunkt für eine Entscheidung, nicht für ein Archiv.

Wenn es schiefgeht

Häufige Fragen (FAQ)

Fazit

Es gibt kein „bestes“ Dateisystem, nur passende und unpassende Paare aus Dateisystem und Aufgabe. Der häufigste Fehler ist nicht die Wahl des falschen Kandidaten, sondern die Erwartung, ein anderes Dateisystem würde Integrität, Redundanz oder Backups mitliefern.

Merksätze zum Mitnehmen:

1. Erst die Ebene, dann den Namen. NFS, CephFS und GlusterFS sind Ergänzungen, keine Alternativen zu ext4 und XFS.
2. ext4 bleibt der Standard, weil Vorhersagbarkeit mehr wert ist als Features, die man nicht wartet.
3. XFS ist für Daten, Btrfs für Zustände. Wer Snapshots, Rollback und Kompression will, nimmt Btrfs oder ZFS — wer Durchsatz unter paralleler Last will, XFS.
4. ZFS ist eine Entscheidung für ein System, nicht für eine Platte. RAM, Vdev-Layout und Betriebsaufwand gehören zur Wahl dazu.
5. Vorsicht bei neuen und bei alten Extremen: bcachefs ist vielversprechend, aber jung; JFS funktioniert, ist aber stehen geblieben. Neueinstiege landen heute meist bei ext4, XFS, Btrfs oder ZFS.