XFS ist ein 64-Bit Journaling-Dateisystem, das ursprünglich von Silicon Graphics (SGI) für IRIX entwickelt wurde. Sein Fokus liegt nicht auf „Features“ wie Snapshots oder Kompression (obwohl es Ansätze dazu gibt), sondern auf extremer Skalierbarkeit und Parallelisierung.
Während ext4 historisch gesehen oft durch Locks (Sperren) limitiert war, wenn viele CPU-Kerne gleichzeitig schreiben wollten, wurde XFS designed, um Hardware-Limits auszureizen. Es geht davon aus, dass du viele Kerne und viele Platten hast.
Kernmechaniken: Das „Warum“ hinter der Technik
Allocation Groups (AGs) – Der Parallelitäts-Motor
Das wichtigste Architektur-Merkmal von XFS ist die Unterteilung des Datenträgers in Allocation Groups (AGs).
Stell dir ext4 wie einen Supermarkt mit nur einer Kasse vor. Wenn 10 Prozesse schreiben wollen, müssen sie sich anstellen (Locking).
XFS unterteilt die Partition in z. B. 4, 8 oder mehr unabhängige Regionen (AGs). Jede AG verwaltet ihre eigenen Inodes und ihren eigenen freien Speicherplatz.
Kausalität:
Wenn du parallel Daten schreibst (z. B. eine Datenbank oder ein Mailserver), weist der Kernel die Schreibvorgänge unterschiedlichen AGs zu.
- Resultat: Prozess A schreibt in AG 1, Prozess B in AG 2. Sie blockieren sich gegenseitig nicht. Das macht XFS zum König des I/O-Durchsatzes auf Multi-Core-Servern.
B+ Bäume (Alles ist indexiert)
Die meisten Dateisysteme nutzen Listen oder einfache Bäume für die Verwaltung von freiem Speicher. XFS nutzt für fast alles B+ Bäume:
- Verfolgung von freiem Speicherplatz.
- Verzeichnis-Indizes.
- Dynamische Inode-Allokation.
Das bedeutet, dass die Performance beim Suchen von freiem Platz oder Dateien nicht linear abnimmt, wenn das Dateisystem voll wird oder Millionen Dateien enthält. Die Zugriffszeit bleibt extrem stabil (O(log n)).
Reflink & CoW (Das „Veeam-Feature“)
Obwohl XFS kein klassisches Copy-on-Write-Dateisystem wie ZFS ist, beherrscht es seit einigen Jahren Reflinks (reflink=1).
Das erlaubt es, Dateien zu „kopieren“, indem einfach neue Pointer auf dieselben Datenblöcke gesetzt werden (ähnlich wie Deduplizierung).
Praxis-Impact (Backup):
Backup-Software wie Veeam nutzt dies für „Fast Clone“. Ein Synthetic Full Backup (Kopieren von alten Backups zu einem neuen Full) passiert fast instantan, ohne dass physische Daten bewegt werden. Das spart Stunden an I/O-Zeit.
Die große architektonische Falle (Shrinking)
Das ist der wichtigste Punkt, den du als Architekt wissen musst: XFS kann nicht verkleinert werden.
Im Gegensatz zu ext4, wo du resize2fs nutzen kannst, um ein Volume zu schrumpfen, ist das bei XFS unmöglich.
- Der Grund: Die Allocation Groups werden bei der Erstellung (mkfs) fix auf der Platte verteilt. Um das Dateisystem zu verkleinern, müsste man Daten aus den hinteren AGs in vordere verschieben und die gesamte Geometrie neu berechnen. Das ist so komplex und riskant, dass die Entwickler es nie implementiert haben.
- Konsequenz: Wenn du eine 10 TB LUN anlegst und merkst, du brauchst nur 5 TB, musst du die Daten wegsichern, das Volume löschen, neu anlegen und restoren. Plane deine LVM-Größen also konservativ (wachsen geht immer:
xfs_growfs).
Metadata Journaling
XFS schreibt nur Metadaten (Dateinamen, Größen, Attribute) in sein Journal, nicht die Nutzdaten selbst.
- Vorteil: Extreme Geschwindigkeit.
- Risiko: Bei einem Stromausfall ist die Dateistruktur garantiert intakt (kein fsck nötig), aber der Inhalt einer Datei, die gerade geschrieben wurde, könnte Nullen enthalten („stale data“).
- Lösung: Moderne Applikationen (Datenbanken) wissen das und nutzen
fsync(), um sicherzustellen, dass Daten wirklich auf der Platte landen.
Tuning für Architekten
External Log (logdev)
Für Datenbank-Server (PostgreSQL/MySQL) ist die Latenz beim Schreiben in das Journal (Write Ahead Log) entscheidend.
Du kannst das XFS-Journal auf ein separates Device legen.
- Setup: Eine kleine, extrem schnelle NVMe für das Journal + ein großes RAID aus HDDs für die Daten.
- Befehl:
mkfs.xfs -l logdev=/dev/nvme0n1 /dev/sdb1 - Effekt: Schreibvorgänge werden nicht durch die Seek-Time der HDDs ausgebremst, da der Commit im schnellen Journal landet.
Inode64
Früher legte XFS alle Inodes in das erste TB der Platte (aus Kompatibilitätsgründen). Auf riesigen Storages führte das dazu, dass Inodes weit weg von ihren Daten lagen (Seek-Time!).
Heute ist inode64 Standard. Stelle sicher, dass es in den Mount-Optionen aktiv ist, damit Inodes überall auf der Platte nah bei ihren Daten liegen dürfen.
Fazit & Abgrenzung
| Feature | ext4 | XFS | ZFS |
| Ziel | General Purpose | Performance & Skalierung | Integrität & Features |
| Max. Dateigröße | 16 TB | 8 Exabyte | 16 Exabyte |
| Verkleinern | Ja | Nein | Nein (Pool-Level) |
| Parallel-I/O | Mittel (Locking) | Exzellent (AGs) | Gut (Transaktionsgruppen) |
| Checkusmmen | Nur Journal | Metadaten (CRC) | Alles (Daten + Meta) |
Wann du XFS nutzt:
- Du betreibst große Datenbanken (geringe Fragmentierung, Direct I/O Support).
- Du nutzt RHEL/CentOS/AlmaLinux (Native Support).
- Du hast riesige Datenmengen (>50 TB) oder riesige Einzeldateien.
- Du nutzt Veeam Repositories (Reflink Support).
Wann nicht:
- Auf kleinen Boot-Partitionen oder USB-Sticks (Overhead zu groß).
- Wenn du Speicherplatz flexibel verkleinern können musst (Virtualisierung/LVM dynamisch).
