ext4 ist der evolutionäre Nachfolger von ext3 und gilt als der „Standard-Treiber“ im Linux-Kernel. Im Gegensatz zu ZFS oder Btrfs ist ext4 ein reines Dateisystem, kein Volume Manager.
Es verwaltet Dateien auf einem gegebenen Block-Device (Partition, LVM-Volume, RAID-Array). Es kümmert sich nicht darum, wo die Daten physisch liegen oder ob eine Festplatte ausfällt. Diese Abstraktion überlässt es den Schichten darunter (LVM/MDRAID).
Design-Ziel: Maximale Stabilität, Rückwärtskompatibilität und Performance bei klassischen Workloads, ohne den Overhead komplexer CoW-Mechanismen (Copy-on-Write).
Kernmechaniken: Das „Warum“ hinter der Technik
Journaling (JBD2)
Um Datenkorruption bei Stromausfällen zu verhindern, nutzt ext4 ein „Journal“ (Write-Ahead-Log). Bevor Metadaten (und optional Nutzdaten) final auf die Platte geschrieben werden, landen sie im Journal.
Nach einem Absturz muss das System nicht die gesamte Platte scannen (fsck), sondern spielt lediglich das Journal erneut ab (Replay).
Architektur-Modi (Mount-Optionen):
data=ordered(Standard): Metadaten kommen ins Journal. Die echten Daten werden zwingend auf die Platte geschrieben, bevor die Metadaten im Journal als „committed“ markiert werden.- Kausalität: Verhindert, dass Dateien existieren, die Müll enthalten. Ein guter Kompromiss aus Sicherheit und Speed.
data=writeback: Nur Metadaten werden journalisiert. Daten können nach den Metadaten geschrieben werden.- Risiko: Bei Absturz hast du vielleicht eine Datei, die die korrekte Größe hat, aber alte Datenreste (Garbage) enthält.
data=journal: Alles (Daten + Metadaten) wird doppelt geschrieben (erst Journal, dann Platte). Extrem sicher, aber halbiert die Schreib-Performance.
Extents (Statt Block-Mapping)
ext3 nutzte eine indirekte Blockadressierung (Listen von Einzelblöcken). Das war bei großen Dateien ineffizient, da der Metadaten-Overhead riesig wurde und die CPU viel rechnen musste.
ext4 nutzt Extents.
Anstatt zu sagen: „Datei A liegt auf Block 1, 2, 3, 4, 5…“, sagt ext4: „Datei A beginnt bei Block 1 und ist 1000 Blöcke lang“.
Implikation:
- Große Dateien werden fast ohne Metadaten-Overhead verwaltet.
- Fragmentierung wird reduziert, da das System versucht, zusammenhängende Bereiche (Contiguous Blocks) zu reservieren.
Delayed Allocation (Delalloc)
ext4 schreibt Daten nicht sofort, wenn der Befehl kommt. Es hält die Daten im RAM (Page Cache) und wartet so lange wie möglich (bis zu 60 Sekunden oder bis der Buffer voll ist), bevor es physische Blöcke zuweist.
Der Vorteil:
Kurlebige Dateien (die erstellt und sofort gelöscht werden) berühren nie die Platte. Für langlebige Dateien kann der Allocator, da er nun die gesamte Dateigröße kennt, eine viel bessere Platzierung auf der Platte berechnen und Fragmentierung vermeiden.
Grenzen & Architektur-Nachteile (vs. ZFS)
Hier zeigt sich das Alter des Designs. Wenn du ext4 einsetzt, musst du wissen, was es nicht kann:
- Keine Daten-Prüfsummen (Data Integrity):ext4 prüft Metadaten (Journal Checksums), aber nicht den Datei-Inhalt.
- Szenario: Wenn ein Bit auf der HDD kippt (Bit Rot), liefert ext4 die korrupte Datei ohne Warnung an die Applikation aus. Es gibt kein „Self-Healing“.
- Keine nativen Snapshots:ext4 kennt keine Snapshots. Du musst LVM (Logical Volume Manager) darunterlegen, um Snapshots zu nutzen. Diese sind aber langsamer als ZFS-Snapshots, da LVM bei Änderungen Blöcke kopieren muss (klassisches CoW auf Blockebene), während ZFS nur Pointer umbiegt.
- Inode-Limitierung:Bei der Formatierung (mkfs.ext4) wird eine feste Anzahl an Inodes (Dateieinträge) angelegt.
- Pain Point: Hast du Millionen winziger Dateien (z. B. Mailserver, Cache-Verzeichnisse), kann das Dateisystem „voll“ sein (keine Inodes mehr), obwohl noch Terabytes an Speicherplatz frei sind. Dies lässt sich nachträglich nicht ändern (nur durch Neuformatierung).
Einzigartige Vorteile (Wann ext4 gewinnt)
Warum nutzen wir es immer noch?
- Shrinking (Verkleinern):Im Gegensatz zu XFS (kann nur wachsen) und ZFS (VDEVs können nicht schrumpfen), kann ein ungemountetes ext4-Dateisystem verkleinert werden (resize2fs). Das ist essenziell für VM-Templates oder das Umpartitionieren im laufenden Betrieb.
- Robustheit:Wenn ZFS crasht, ist oft der Pool weg. Wenn ext4 crasht, retten Tools wie e2fsck fast immer zumindest einen Teil der Daten nach lost+found. Es ist extrem verzeihlich bei Hardware-Fehlern.
- Overhead:ext4 benötigt kaum RAM und CPU. Es läuft auf einem Raspberry Pi genauso gut wie auf einem Enterprise-Server.
Tuning für Systemarchitekten
Wenn du ext4 auf Servern deployest, nutze diese Stellschrauben:
Reserved Blocks (-m)
Standardmäßig reserviert ext4 5% des Platzes für den root-User und Systemdienste, damit das System nicht crasht, wenn die Platte vollläuft.
- Problem: Bei einer 10 TB Platte sind das 500 GB verschwendeter Platz.
- Fix: Setze es auf 1% oder 0% für reine Daten-Platten:
tune2fs -m 0 /dev/sdX1
Dir_index (HTree)
Sorgt dafür, dass Verzeichnisse nicht als lineare Liste, sondern als Hash-Baum (H-Tree) gespeichert werden.
- Kausalität: Beschleunigt Dateizugriffe in Ordnern mit Tausenden von Dateien massiv. Ist heute meist Standard (
tune2fs -l /dev/sdX | grep dir_index).
Mount-Optionen
noatime(oderrelatime): Deaktiviert das Schreiben des Zugriffszeitstempels bei jedem Lesevorgang. Spart massive IOPS.discard: Aktiviert TRIM für SSDs direkt beim Löschen.- Best Practice: Nutze lieber nicht die Mount-Option, sondern einen systemd-Timer (
fstrim.timer), der das wöchentlich macht. Live-Discard kann bei hoher Last die Performance bremsen.
- Best Practice: Nutze lieber nicht die Mount-Option, sondern einen systemd-Timer (
Fazit
ext4 ist der Toyota Hilux unter den Dateisystemen. Es fehlen die modernen Features (Kompression, Deduplizierung, Bit-Rot-Schutz), aber es bringt dich immer ans Ziel.
Einsatzempfehlung:
- System-Partitionen (Root / Boot): Immer ext4. Einfachheit siegt hier.
- VM-Images (als Gast-FS): ext4, da geringer Overhead.
- Daten-Grab (NAS): Hier verliert ext4 gegen ZFS, da die Datenintegrität fehlt.
