Linux & Betriebssysteme

Linux-Dateisysteme im Vergleich: ext4, XFS, Btrfs und ZFS

Linux kennt mehrere Dateisysteme, und die Wahl hat spürbare Folgen: Leistung bei vielen kleinen Dateien, Verhalten bei einem Stromausfall, Möglichkeiten für Momentaufnahmen und der Aufwand im Betrieb. Dieser Artikel vergleicht die vier, die in der Praxis relevant sind.

Die vier Kandidaten

  • ext4 – der Standard. Ausgereift, schnell, überall verfügbar, Werkzeuge zur Reparatur vorhanden. Keine Momentaufnahmen, kein Prüfsummenschutz für Daten.
  • XFS – der Standard auf Servern mit großen Dateien und hohem Durchsatz. Sehr gute Leistung bei parallelen Schreibvorgängen, Online-Vergrößerung. Verkleinern ist nicht möglich.
  • Btrfs – Momentaufnahmen, Prüfsummen, Kompression, Untervolumes. Ideal für Momentaufnahmen-basierte Sicherungen und Container-Speicher.
  • ZFS – Datensicherheit an erster Stelle: Prüfsummen für alles, Selbstheilung, RAID im Dateisystem, Deduplizierung. Höherer Speicherbedarf, komplexere Regeln.

Wo die Unterschiede herkommen

Momentaufnahmen (Snapshots)
  ext4   nein (nur ueber LVM moeglich)
  XFS    nein (nur ueber LVM moeglich)
  Btrfs  ja, sofort, platzsparend ("copy-on-write")
  ZFS    ja, sofort, mit eigener Verwaltung
  -> Fuer "Sicherung vor einem Update" ist das der
     entscheidende Unterschied. Bei ext4 braucht es LVM.

Pruefsummen fuer DATEN (nicht nur Metadaten)
  ext4   nur Metadaten -> stille Datenfehler bleiben unentdeckt
  XFS    nur Metadaten
  Btrfs  Daten und Metadaten -> Fehler werden erkannt
  ZFS    Daten und Metadaten -> erkannt UND (mit Redundanz) behoben

  Bedeutung: Ein "stiller Datenfehler" ist eine Datei, die
  Bitfehler enthaelt, ohne dass das System es merkt. Bei
  Btrfs/ZFS wird der Fehler gemeldet; bei ext4/XFS liefert
  das System beschuedigte Daten aus.

Kompression
  ext4/XFS  nein
  Btrfs     zstd, lzo, zlib - transparent, spart Platz
  ZFS       lz4 (Standard), zstd, gzip - sehr effizient

Verkleinern
  ext4   ja (resize2fs, offline)
  XFS    NEIN - nur vergroessern!
  Btrfs  ja, online
  ZFS     per Pool-Neuanlage oder Umbau

Speicherverbrauch
  ext4/XFS  gering
  Btrfs     moderat
  ZFS       hoch: ARC (Zwischenspeicher) braucht viel RAM;
            Regel: 1 GB RAM je 1 TB Speicher, mindestens 8 GB

Momentaufnahmen: das stärkste Argument für Btrfs und ZFS

# Btrfs - Momentaufnahme vor einem Update (Sekundenbruchteile)
btrfs subvolume snapshot / /snapshots/root-$(date +%F-%H%M)
btrfs subvolume list /
btrfs filesystem df /
btrfs filesystem usage /

# Momentaufnahmen sind "copy-on-write": Sie kosten fast keinen
# Platz und sind sofort erstellt. Perfekt vor:
#   - Systemaktualisierungen
#   - Konfigurationsaenderungen an Diensten
#   - Tests, deren Ergebnis man zuruecknehmen will

# Btrfs send/receive: inkrementelle Sicherung
btrfs send /snapshots/root-heute | ssh ziel "btrfs receive /srv/backup/"
#   Nur die Unterschiede zur vorherigen Momentaufnahme werden
#   uebertragen - sehr effizient fuer taegliche Sicherungen.

# ZFS - dasselbe Prinzip
zfs snapshot tank/root@vor-update-$(date +%F)
zfs list -t snapshot
zfs list -o name,used,refer tank/root
zfs rollback tank/root@vor-update-2026-09-26
zfs send tank/root@heute | ssh ziel zfs receive backup/root
zfs destroy tank/root@alt

# Platzverbrauch verstehen: Eine Momentaufnahme kostet nichts,
# solange sich die Daten nicht aendern. Wird eine Datei geaendert,
# wird der ALTE Block von der Momentaufnahme gehalten.
#   -> Langfristig aufbewahrte Momentaufnahmen koennen viel
#      Platz belegen. Aufbewahrungspolitik ist Pflicht!

Leistung: was wann schneller ist

Viele kleine Dateien (Mailserver, Git, node_modules)
  ext4  gut
  XFS   gut, bei parallelem Zugriff sehr gut
  Btrfs langsamer bei Metadatenoperationen
  ZFS   langsamer, profitiert stark vom ARC

Grosse Dateien, sequenzieller Durchsatz
  XFS   sehr gut, oft die beste Wahl
  ext4  gut
  Btrfs gut
  ZFS   gut, mit LZ4-Kompression oft sogar besser als unkomprimiert
        (weniger Datentraegerverkehr)

Datenbanken
  XFS   haeufig empfohlen (PostgreSQL, MySQL)
  ext4  ebenfalls bewaehrt
  Btrfs Datenbankdateien mit eigener Sync-Strategie sind heikel;
        auf CoW-Verzeichnis (chattr +C) achten
  ZFS   mit gesetztem recordsize und sync=standard gut geeignet

Faustregel:
  Standardfall, wenig Aufwand         -> ext4
  Server mit viel Durchsatz           -> XFS
  Momentaufnahmen und Kompression     -> Btrfs
  Datensicherheit an erster Stelle    -> ZFS

ext4 im Alltag

# Anlegen
mkfs.ext4 -L daten -m 1 /dev/vg0/daten
#   -m 1 : nur 1 % reservierte Bloecke fuer root
#          Standard ist 5 % - bei grossen Platten viel verschenkt.
#          Nur auf der Root-Partition bei 5 % belassen!

# Pruefen und anpassen
dumpe2fs -h /dev/vg0/daten | head -30
tune2fs -m 1 /dev/vg0/daten            # reservierte Bloecke aendern
tune2fs -l /dev/vg0/daten | grep -E 'Filesystem state|Mount count'

# Vergroessern (online moeglich)
lvextend -L +50G /dev/vg0/daten
resize2fs /dev/vg0/daten

# Pruefen (NICHT auf einer eingehaengten Partition!)
umount /dev/vg0/daten
fsck.ext4 -f /dev/vg0/daten
#   Fehlerpruefung kann bei grossen Dateisystemen Stunden dauern.
#   Das ist der Preis fuer den fehlenden Pruefsummenschutz.

# Einhaengen
# /etc/fstab
# UUID=...  /daten  ext4  defaults,noatime,nodiratime  0 2
#   noatime: kein Zugriffszeitstempel -> weniger Schreibzugriffe
#   Das ist bei Servern fast immer sinnvoll.

Prüfliste

  1. Passt die Wahl zum Zweck – Durchsatz, viele kleine Dateien, Momentaufnahmen?
  2. Reservierte Blöcke bei großen Datenpartitionen angepasst (-m 1)?
  3. noatime gesetzt (weniger Schreiblast)?
  4. Ist die Momentaufnahmepolitik festgelegt, wenn Btrfs oder ZFS genutzt wird? Sonst füllt sich die Platte.
  5. Sind Prüfläufe geplant – und getestet, wie lange sie dauern?
  6. Ist der Speicherbedarf bei ZFS eingeplant (ARC, mindestens 8 GB)?
  7. Ist die Wiederherstellung aus einer Momentaufnahme einmal geübt worden?
  8. Ist die Warnung bekannt, dass XFS nicht verkleinert werden kann?

Die häufigsten Fehler

  1. Momentaufnahmen als Sicherung ansehen. Eine Momentaufnahme liegt auf demselben Datenträger. Fällt der aus, sind Daten und Momentaufnahme weg. Sie ist eine Absicherung gegen Fehler, nicht gegen Hardwareausfall.
  2. Momentaufnahmen nie aufräumen. Bei rege geänderten Daten belegen sie schnell mehr Platz als die Originaldaten.
  3. Btrfs ohne CoW-Ausnahme für Datenbankdateien. Doppelte Absicherung kostet Leistung und kann Fragmentierung erzeugen: chattr +C auf dem Verzeichnis vor der ersten Datei.
  4. ZFS mit zu wenig Speicher. Ohne ausreichend RAM werden Prüfsummen und Zwischenspeicher zum Flaschenhals.
  5. ZFS-Pool ohne Redundanz. Ein Pool aus einer einzigen Platte erkennt Fehler, kann sie aber nicht beheben – die Selbstheilung braucht Redundanz (Spiegel oder RAID-Z).
  6. fsck auf einer eingehängten Partition. Führt zu schweren Schäden. Vorher aushängen.
  7. Keine Verzeichnisstruktur nach Zweck. Protokolle, Datenbanken und Archive haben unterschiedliche Anforderungen an Durchsatz und Aufbewahrung – ein Dateisystem für alles ist selten optimal.

Verwandte Grundlagen: Dateisystem, Linux-Dateirechte, LVM, RAID-Ebenen.