XFS vs EXT4 auf NVMe-Servern: Benchmarks und Praxisvergleich

Ich vergleiche XFS EXT4 auf NVMe-Servern anhand aktueller Benchmarks und Praxiswerten und zeige, wann welches Dateisystem messbar vorne liegt. Dabei konzentriere ich mich auf Durchsatz, Latenzen und reale Workloads, damit du die NVMe-Leistung im Server zielgerichtet nutzt.

Zentrale Punkte

Zum Einstieg fasse ich die wichtigsten Erkenntnisse kurz zusammen, bevor ich in Details, Benchmarks und Tuning einsteige.

• Random I/O: Beide sehr nah beieinander, EXT4 minimal mehr Durchsatz, XFS gleichmäßigere Latenzen.
• Sequenziell: XFS oft vorn bei großen Dateien, EXT4 knapp dahinter mit soliden Raten.
• Metadaten: EXT4 teils kleine Vorteile, XFS mit konstanten Antwortzeiten.
• Applikationen: In Datenbanken Kopf-an-Kopf, Unterschiede im niedrigen Prozentbereich.
• Tuning: Kernel, Scheduler, I/O-Tiefe, freier Platz und Mount-Optionen machen den Unterschied.

XFS und EXT4 auf NVMe: technische Einordnung

EXT4 gilt als bewährter Linux-Standard, liefert auf NVMe eine sehr zuverlässige Basis und dient in vielen Vergleichen als Referenz. XFS adressiert große Dateien, hohe Parallelität und sequentielle Datenströme und kann NVMe-Durchsatz sehr gut ausschöpfen. Auf moderner Hardware schrumpfen die Abstände, weil beide Dateisysteme jahrelang gereift sind und neue Kernel-Versionen den NVMe-Stack weiter optimieren. In Alltags-Workloads entscheiden oft die Lastprofile: viele kleine, zufällige Zugriffe liegen sehr eng zusammen, große sequentielle Transfers bevorzugen tendenziell XFS. Wer Entscheidungen trifft, sollte deshalb sein I/O-Profil kennen und nicht nur auf allgemeine Ranglisten schauen.

Random I/O auf NVMe: kleine Blöcke, hohe Parallelität

Bei 4K- und 8K-Zugriffen liefern beide Dateisysteme IOPS auf einem sehr ähnlichen Niveau, oft innerhalb weniger Prozentpunkte. EXT4 zeigt in manchen Messungen minimal höhere Durchschnittswerte beim Random-Write, was in OLTP-ähnlichen Szenarien sichtbar sein kann. XFS glänzt dagegen mit gleichmäßigeren Latenzen und weniger Jitter über längere Laufzeiten, was bei gemischten Lasten planbare Antwortzeiten begünstigt. In produktiven Umgebungen überdecken Caches, Applikationslogik und Netzwerkpfade diese feinen Unterschiede häufig. Damit rücken andere Stellschrauben wie Buffer-Cache, WAL-Strategie oder I/O-Depth in den Vordergrund (Quelle: 1, 4, 7).

Sequenzielle Transfers: große Dateien effizient bewegen

Bei MB-großen Blöcken und langen, sequentiellen Streams hat XFS häufig die Nase vorn, weil das Extent-Layout große Dateien effizient verwaltet. Backup-Fenster, Archivjobs und sequentielle Checkpoints profitieren davon spürbar, besonders auf PCIe 4.0/5.0 NVMe. EXT4 bleibt nahe dran und liefert sehr gute Raten, die in vielen Setups kaum limitieren. Je länger der Stream und je größer die Datei, desto deutlicher pendelt der Vorteil zu XFS. Einen ergänzenden Überblick bietet mein kurzer Performance-Vergleich mit typischen Server-Workloads (Quelle: 4, 5, 9).

Metadaten-Operationen: viele kleine Dateien

Workloads mit vielen Datei-Operationen fordern die Metadatenpfade und bringen Unterschiede bei Locking und Journaling ans Licht. EXT4 liegt bei schnellem Anlegen/Löschen vieler kleiner Dateien in manchen Tests knapp vorn. XFS hält mit konstanten Latenzen dagegen und bleibt dadurch gut planbar für Logs, Caches und Build-Verzeichnisse. Im Vergleich zu alternativen Dateisystemen zeigen beide eine ausgereifte Verwaltung und nachvollziehbare Reaktionsmuster. Wer massenhaft kleine Dateien bewegt, sollte die Mount-Optionen beachten und praxisnahe Tests über längere Zeiträume laufen lassen (Quelle: 1, 7, 13).

Benchmark-Überblick in Zahlen

Die folgenden Tendenzen fasse ich kompakt zusammen, damit du typische Muster schnell erkennst. Random I/O mit kleinen Blöcken: Unterschiede meist gering, oft im Bereich ±3–5 % bei IOPS. Sequenziell mit großen Blöcken: XFS häufig vorn, besonders bei langen Streams und großen Dateien. Metadatenlastige Tests: teils kleiner EXT4-Vorteil, XFS mit gleichmäßigen Latenzen. In analytischen Szenarien nutzen beide Dateisysteme häufig rund 80–85 % der theoretischen NVMe-Leistung, abhängig von Kernel, Treiber und Controller-Firmware (Quelle: 1, 3, 4, 5, 10).

Szenario	Tendenz	Typischer Vorteil	Hinweis
Random I/O (4K/8K)	Sehr eng	EXT4 geringfügig mehr Durchsatz	XFS oft glattere Latenzen
Sequenziell (≥1 MB)	XFS vorn	Höherer Durchsatz bei großen Dateien	Lange Streams verstärken Effekt
Metadaten-Operationen	Kopf-an-Kopf	EXT4 teils schneller bei Create/Delete	XFS konstant bei gemischter Last
Datenbanken (OLTP)	Sehr eng	EXT4 minimal höhere TPS	XFS gleichmäßigere Antwortzeiten
Analytics/Reporting	Eng	XFS bei großen Scans	Beide nutzen 80–85 % der HW

Applikationsnahe Benchmarks: Datenbanken und gemischte Last

In PostgreSQL- oder MySQL-Tests sehe ich ein Kopf-an-Kopf-Rennen, das von Latenzprofilen, WAL-Strategien und Buffer-Cache-Einstellungen lebt. EXT4 liefert teils eine Nuance mehr Transaktionen pro Sekunde unter hoher Parallelität. XFS punktet mit stabilen Antwortzeiten, was tail latencies in kritischen APIs glätten kann. Die Unterschiede bleiben klein genug, dass Datenbank-Tuning mehr Effekt zeigt als der reine Dateisystemwechsel. Wer entscheidet, sollte daher Workload-typische Dauerläufe messen und die Applikationsmetriken sorgfältig beobachten (Quelle: 2, 3, 9).

Kernel-Version, NVMe-Modelle und ihr Einfluss

Neuere Linux-Kernel der 5.x- und 6.x-Linien reduzieren Latenzen und heben Durchsatz, was beiden Dateisystemen auf schnellen NVMe zugutekommt und Engstellen im I/O-Stack mindert. Enterprise-SSDs mit großem DRAM-Cache und Power-Loss-Protection kaschieren Unterschiede zusätzlich, weil Controller und Firmware limitieren, bevor das Dateisystem ins Gewicht fällt. Günstige Consumer-NVMe zeigen die Spanne deutlicher, bleiben aber im Alltag meist nah beieinander. PCIe 4.0/5.0 erhöht den Headroom, wodurch sequentielle Vorteile von XFS sichtbarer werden. Kernel-Updates, NVMe-Firmware und saubere Treiberstände zahlen sich deshalb messbar aus (Quelle: 1, 5, 10, 11).

Tuning auf NVMe: Scheduler, I/O-Tiefe, freier Platz

Ich starte oft mit einem schlichten Scheduler wie none oder mq-deadline und passe die I/O-Depth je Workload an, um Warteschlangen sinnvoll zu füllen. Zu hohe Depth erzeugt Latenzspitzen, zu niedrige verschenkt parallele Ressourcen. 15–20 % freien Platz einzuplanen reduziert Fragmentierung und hält Allocations zügig. Für XFS schaue ich mir die Aufteilung in Allocation Groups an, weil sie die Parallelität des Dateisystems maßgeblich prägen; ein gutes Einstiegsthema sind die XFS Allocation Groups. Jede Änderung messe ich im A/B-Vergleich, damit Effekte nachvollziehbar bleiben und keine Verschlechterungen durchrutschen.

Mount-Optionen gezielt nutzen

Mount-Optionen beeinflussen Journaling, Commit-Intervalle und Schreibpfade und können Latenz und Durchsatz spürbar verschieben. EXT4 bietet sinnvolle Hebel bei Journal-Modus und Commit-Zeiten, während XFS Optionen für Log-Buffers und Inode-Parameter bereithält. Ich passe diese Einstellungen nach Lastprofil an und dokumentiere jede Änderung. Wer tiefer einsteigen will, findet kompakte Hinweise zu sinnvollen Parametern in den EXT4 Mount-Optionen. Wichtig bleibt, jede Mount-Anpassung mit realen Workloads zu prüfen, nicht nur mit synthetischen Tests.

Hosting-Praxis: Auswahl nach Workload

Für klassische Webanwendungen mit CMS und Shops liefert EXT4 eine verlässliche Basis, weil viele kleine Dateien und gemischte I/O-Muster dominieren. Datenbanken mit hoher Parallelität laufen auf beiden Dateisystemen sehr gut; ich entscheide nach bestehenden Erfahrungswerten, Monitoring-Setup und Backup-Konzept. Große sequentielle Datenströme bei Backups und Archiven begünstigen XFS, was Transferfenster strafft. Analytics-Workloads profitieren ebenfalls vom XFS-Handling großer Scans, während gemischte Profile oft kaum Unterschiede zeigen. Wer unsicher ist, setzt ein Staging-System auf und misst entlang der wichtigsten Tageslasten.

Teststrategie: realitätsnah und messbar

Ich kombiniere kurze Peak-Tests mit langen Dauerläufen, damit ich sowohl Maximalwerte als auch Jitter und Alterungseffekte sehe. Statt nur synthetischen Tools setze ich Kopien produktiver Datenbanken, typische Logfiles und reale Import-/Export-Jobs ein. Monitoring mit iostat, perf und Applikationsmetriken läuft immer mit, damit ich Korrelationen eindeutig belegen kann. Die Tests wiederhole ich nach Kernel-Updates oder Firmwarewechseln, um Regressionen früh zu erkennen. So zeigt sich, ob XFS oder EXT4 in der eigenen Umgebung den besseren Kompromiss aus Durchsatz, Latenz und Vorhersagbarkeit liefert (Quelle: 1).

Journaling, Barrieren und Sync-Semantik auf NVMe

Journaling-Details entscheiden mit über Latenzspitzen und Recovery-Verhalten. EXT4 nutzt standardmäßig data=ordered und schreibt Metadaten ins Journal, während Nutzdaten vor dem Commit persistiert werden. Wer maximale Schreibrate bei akzeptiertem Risiko braucht, kann data=writeback erwägen, was jedoch Replays nach Abstürzen erschwert. Neuere EXT4-Versionen unterstützen fast_commit, was viele kleine Metadaten-Transaktionen bündelt und Commit-Zeiten verkürzt. XFS führt ein eigenes Log (Journal), dessen logbsize und logbufs die Parallelität und Latenz deutlich beeinflussen. Auf NVMe sind Write Barriers wichtig: Ohne Power-Loss-Protection sollten Barrieren aktiv bleiben, um Reordering der Controller-Firmware abzusichern. Mit PLP kann man Barrieren gezielt reduzieren, um fsync()-schwere Lasten zu beschleunigen – stets gegen das Risiko abwägen. Für Applikationen mit striktem Durability-Anspruch (z. B. Datenbanken) ist ein sauberes fsync()-Verhalten wichtiger als einzelne Prozentpunkte mehr Durchsatz.

TRIM/Discard und Langzeitverhalten der NVMe

Auf Flash beeinflussen Discard/Trim-Strategien die nachhaltige Schreibleistung. Inline-Discard beim Mount (discard/async_discard) reduziert Hintergrundarbeit des Controllers, kann aber unter Last Latenzspitzen erzeugen. Periodische fstrim-Läufe (z. B. wöchentlich) halten in vielen Produktionsumgebungen die Performance konstanter und entkoppeln die Freigabe ungenutzter Blöcke vom Hot-Path. XFS verarbeitet Discards effizient in Batches, EXT4 bietet mit discard=async eine weiche Variante. Wichtig ist, Discard durch alle Schichten (dm-crypt, LVM, MD-RAID, Hypervisor) sauber zu propagieren. Werden langfristig 15–20 % Reserve freigehalten, reduziert sich die interne Garbage Collection – Latenzjitter sinkt, die Schreibleistung bleibt stabiler.

RAID, LVM und Verschlüsselung: Schichten richtig abstimmen

Vor dem Formatieren sollte die Block-Geometrie zu RAID/LVM passen. Für XFS definiert die richtige Wahl von sunit/swidth (Allocation-Alignment) die Effizienz großer sequentieller Transfers; bei EXT4 tun dies stride/stripe-width. Stimmt das Alignment, minimieren sich Read-Modify-Write-Zyklen im RAID. LVM-Thin und Snapshots sind praktisch, erhöhen aber die Latenz in Schreibpfaden – das fällt bei Random-Workloads stärker ins Gewicht als bei reinen Scans. dm-crypt/LUKS kostet CPU und kann bei kleinen Blöcken die IOPS limitieren; moderne AES-NI/ARM-Crypto helfen, doch die Tail-Latencies steigen typischerweise leicht. Für verschlüsselte Volumes lohnt es, I/O-Depth und Queue-Affinitäten neu zu justieren und Discard explizit zu erlauben, falls Sicherheitsrichtlinien dies zulassen.

CPU/NUMA, Interrupt-Affinität und io_uring: Latenzfeintuning

NVMe skaliert über mehrere Submission/Completion-Queues; wer NUMA-Lokalität beachtet, reduziert Cross-Node-Hops. NVMe-IRQs und die Worker-Threads der Applikation sollten auf demselben NUMA-Knoten laufen, auf dem der Speicher allokiert ist. In Linux helfen IRQ-Pinning und angepasste rps/xps-Einstellungen, den Datenpfad lokal zu halten. Moderne Workloads profitieren von io_uring (statt älterem AIO), das syscalls reduziert und Batch-Submission erlaubt. In fio-Tests zeigt sich das als niedrigere Latenzen bei gleicher IOPS. Zu hohe Queue-Tiefen (iodepth) verschmieren jedoch die Latenzverteilung; sinnvoll sind abgestufte Tests (z. B. 1, 4, 16, 64), um das Sweet-Spot pro Workload zu identifizieren.

Container- und VM-Umgebungen: Besonderheiten im Stack

Unter Containern (overlayfs) war XFS lange der Standardtipp, weil d_type früh zuverlässig verfügbar war und große Layer-Sets effizient verwaltet wurden. Heute liefern moderne EXT4-Deployments gleichwertige Stabilität; Performance-Unterschiede sind klein und eher overlayfs- als FS-getrieben. In VMs dominieren die Virtio-/NVMe-Frontends und Caching-Modi des Hypervisors: cache=none plus O_DIRECT im Gast reduziert Double-Buffering. Wichtig sind Discard-Durchreichung und einheitliche Sektorgrößen (4K vs. 512e), um Write-Amplification zu vermeiden. Snapshot-getriebene Plattformen (z. B. QCOW2, ZVOL) fügen Copy-on-Write ein; die Dateisystemwahl im Gast bleibt relevant, doch das Host-Backend limitiert oft früher als XFS/EXT4 selbst.

Wiederherstellung, Konsistenz und Wartungsfenster

Beide Dateisysteme gelten als robust, doch die Wartungswege unterscheiden sich. EXT4 lässt sich mit e2fsck gründlich prüfen; auf sehr großen Volumes dauert das im Fehlerfall spürbar, profitiert aber von inkrementellen Verbesserungen (Fast-Commit verkürzt Replays kleinerer Transaktionen). XFS ist auf Online-Konsistenz ausgelegt; tiefe Prüfungen laufen mit xfs_repair, das im Ernstfall viel RAM benötigt und bei sehr großen Bäumen Zeit beanspruchen kann. Für produktive Systeme lohnt ein fsfreeze vor LVM-/Storage-Snapshots, um applikationskonsistente Sicherungen zu erhalten; Datenbanken sollten zusätzlich ihre eigenen Checkpoint-/Backupmechanismen triggern. Wer SLAs mit kurzen RTO/RPO hat, plant Wiederherstellungstests explizit ein – das entzaubert Mythen und zeigt realistische Downtime-Fenster.

Feature-Aspekte jenseits von Rohleistung

Leistung ist nicht alles. XFS bietet Reflink-basierte Kopien und Dedupe-Hooks, was für VM-Images und große Medienbestände Speicher spart und Kopierzeiten verkürzt. EXT4 punktet mit breiter Tool-Unterstützung und konservativen Defaults, die Rollouts vereinfachen. Quotas sind in beiden Welten verfügbar; XFS glänzt mit Project-Quotas für verzeichnisbasierte Kontingente großer Multitenant-Strukturen. Optionen wie noatime/relatime/lazytime reduzieren Metadaten-Schreiblast spürbar. Wer per-Verzeichnis- oder per-Datei-Verschlüsselung nutzt (fscrypt), sollte den leichten Overhead bei kleinen Random-Zugriffen einkalkulieren und CPU-Reserven vorhalten.

Messfehler vermeiden: typische Fallstricke

Viele vermeintliche FS-Unterschiede sind in Wahrheit Testartefakte. Zu kleine Datensätze landen im Page Cache und kaschieren Unterschiede; Datensätze sollten größer als der verfügbare RAM sein. Ein fehlendes warm-up verfälscht Random-Write-Profile auf Flash; ebenso führen parallel laufende Maintenance-Jobs (Scrubs, Rebuilds, fstrim) zu Ausreißern. Bei fio-Tests muss klar sein, ob direct=1 genutzt wird, ob fsync()-Phasen realistisch gesetzt sind und ob Read/Write-Mixe interleaved oder in Phasen laufen. Reproduzierbare Ergebnisse brauchen feste CPU-Frequenzen (keine aggressiven Scaling-Governors), konstante Hintergrundlast und saubere Isolation von Test und Monitoring.

Praxis-Checkliste: so gehst du vor

• Workload-Profil klären: Blockgrößen, Read/Write-Verhältnis, Latenzbudget, Burst-Verhalten.
• Stack aufräumen: Kernel, NVMe-Firmware, Treiberstände; IRQ-Affinität und NUMA prüfen.
• Layout ausrichten: RAID-/LVM-Alignment (sunit/swidth bzw. stride/stripe-width) korrekt setzen.
• Mount-Optionen testen: Barrieren, Commit-Intervalle, noatime/relatime/lazytime; XFS-Log-Parameter.
• I/O-Depth kalibrieren: Latenz vs. Durchsatz abwägen, Sweet-Spot je Applikation finden.
• Freien Platz einplanen: 15–20 % Reserve für gleichmäßige Latenzen und weniger Fragmentierung.
• Discard-Strategie definieren: Inline vs. periodisches fstrim, durch alle Schichten propagieren.
• Backups & Recovery: fsfreeze-/Snapshot-Prozesse testen, Downtime realistisch verifizieren.
• A/B-Messungen: Nur eine Variable ändern, Ergebnisse mit Applikationsmetriken korrelieren.

Zusammenfassung: Entscheidungshilfe ohne Mythen

XFS und EXT4 liefern auf NVMe sehr hohe Leistung, die Unterschiede bleiben meist moderat und hängen stark vom I/O-Profil ab. Random-Lasten mit kleinen Blöcken liegen dicht beieinander, während lange sequentielle Streams XFS tendenziell nach vorne bringen. EXT4 überzeugt mit leicht höherem Durchsatz in einigen transaktionalen Mustern, XFS mit konstanten Latenzen über Dauerläufe. Kernel-Stand, NVMe-Modelle, Scheduler, I/O-Depth, freier Platz und Mount-Optionen beeinflussen das Ergebnis oft stärker als die Dateisystemwahl allein. Wer klar misst und die eigenen Workloads versteht, trifft eine fundierte Entscheidung – ohne Legenden und mit messbarem Gewinn.