Xfs Grundsätzliches

Was ist XFS?

XFS ist ein 64-Bit-Journaling-Dateisystem für UNIX-ähnliche Betriebssysteme, entwickelt von Silicon Graphics Inc. (SGI).
Ursprünglich in den 1990er Jahren für IRIX und High-Performance-Computing-/Serverumgebungen entwickelt, seit 2001 im Linux-Kernel-Hauptzweig enthalten.
Heute Standard-Dateisystem bei Red Hat/Rocky/CentOS.

Kerncharakteristik

Journaling-Dateisystem (kein Copy-on-Write wie btrfs/ZFS)
Aufbau in unabhängigen Allocation Groups (AGs) statt klassischer Block Groups
Online-Grow möglich, Shrink nicht unterstützt
Sehr gute Skalierung bei großen Dateien und hoher Parallelität – ausgelegt auf Dateisystemgrößen bis in den Exabyte-Bereich sowie sehr hohe Datei-/Verzeichnisanzahlen

Erweiterte Funktionen

ACLs (Access Control Lists)
Erweiterte Attribute (xattr)
Quota-Unterstützung

Architektur-Überblick

Auch ext4 unterteilt das Volume in Block Groups – der entscheidende Unterschied zu XFS liegt also nicht in der Gruppierung an sich, sondern in Zweck und Locking-Granularität:

Ext4 Block Groups

Primär für Locality gedacht (Inodes nah bei ihren Datenblöcken halten, kurze Seek-Wege auf HDDs)
Allokation läuft faktisch über einen globalen Allocator, der sich Group für Group durcharbeitet – im Kern seriell

XFS Allocation Groups (AGs)

Für echte Parallelität designed – praktisch unabhängige Mini-Dateisysteme innerhalb eines Devices
Jede AG hat eigene AGF/AGI-Locks, wodurch mehrere Prozesse/Threads gleichzeitig in verschiedenen AGs allozieren können, ohne sich gegenseitig zu blockieren

Merksatz: Beide haben Gruppen – ext4 nutzt sie für Locality (seriell), XFS nutzt sie für Locking-Granularität (parallel).

+------------------------------------------------------------+
|                     XFS Filesystem                         |
|  +-----------+  +-----------+  +-----------+  +-----------+ |
|  |   AG 0    |  |   AG 1    |  |   AG 2    |  |   AG N    | |
|  | Superblock|  |  (Copy)   |  |  (Copy)   |  |  (Copy)   | |
|  |    AGF    |  |    AGF    |  |    AGF    |  |    AGF    | |
|  |    AGI    |  |    AGI    |  |    AGI    |  |    AGI    | |
|  | Inodes    |  | Inodes    |  | Inodes    |  | Inodes    | |
|  | Datenbl.  |  | Datenbl.  |  | Datenbl.  |  | Datenbl.  | |
|  +-----------+  +-----------+  +-----------+  +-----------+ |
+------------------------------------------------------------+

Mermaid-Diagramm: Struktur einer Allocation Group

graph TD FS[XFS Volume] --> AG0[Allocation Group 0] FS --> AG1[Allocation Group 1] FS --> AGN[Allocation Group N ...] AG0 --> SB[Superblock - primär] AG0 --> AGF0[AGF - Free Space B+Trees] AG0 --> AGI0[AGI - Inode B+Tree] AG0 --> IN0[Inodes] AG0 --> DB0[Datenblöcke] AG1 --> SB1[Superblock - Kopie] AG1 --> AGF1[AGF] AG1 --> AGI1[AGI] AG1 --> IN1[Inodes] AG1 --> DB1[Datenblöcke]

Die zentralen Metadaten-Strukturen

Superblock

Nur in AG 0 der "echte" Superblock, in allen weiteren AGs liegt jeweils nur eine Kopie zur Redundanz/Recovery
Enthält globale Filesystem-Parameter (Blockgröße, AG-Größe, Inode-Größe, UUID, ...)

AGF (Allocation Group Free Space)

Verwaltet den freien Platz innerhalb dieser AG
Zwei parallele B+Trees:
- sortiert nach Blocknummer (für Locality-Suche, "finde freien Extent nahe an bestehenden Daten")
- sortiert nach Extent-Größe (für "finde den passenden freien Extent für Allokation dieser Größe")

AGI (Allocation Group Inode Information)

Verwaltet Inodes ohne feste Bitmap (Unterschied zu ext4!)
Inodes werden dynamisch per B+Tree verwaltet, nicht in einem vorab reservierten Inode-Table-Bereich
Dadurch ist die Anzahl der Inodes bei XFS nicht wie bei ext4 beim `mkfs` fest vorgegeben, sondern wächst dynamisch mit Bedarf

B+Trees allgemein

XFS verwendet an fast jeder Stelle B+Trees statt linearer Bitmaps (Free Space, Inodes, Extents, Verzeichniseinträge bei großen Directories)
Vorteil: Suchen/Einfügen/Löschen in O(log n) statt linearem Scan – deutlich performanter bei großen, stark frequentierten Dateisystemen

Delayed Allocation

XFS reserviert beim Schreiben zunächst nur virtuell Platz im RAM (Extent-Reservierung), die tatsächliche physische Blockzuweisung erfolgt erst beim Flush auf Platte.

sequenceDiagram participant App as Applikation participant Cache as Page Cache participant XFS as XFS Allocator participant Disk as Platte App->>Cache: write() Daten Cache->>XFS: Extent virtuell reservieren Note over XFS: noch keine physische Zuweisung Cache->>Cache: weitere writes sammeln sich Cache->>XFS: Flush (z.B. durch fsync/Timer) XFS->>Disk: EINE zusammenhängende Extent-Zuweisung

Vorteil

Dadurch können viele kleine Schreiboperationen zu einem großen zusammenhängenden Extent zusammengefasst werden → deutlich weniger Fragmentierung bei sequentiellen Workloads (Datenbank-Dumps, Log-Files, große Kopiervorgänge).

XFS ist kein Copy-on-Write

Eigenschaft	ext4 / XFS	btrfs / ZFS
Schreibprinzip	Overwrite in-place	Copy-on-Write
Crash-Konsistenz	Metadaten-Journal (Redo/Replay)	nie durch Crash inkonsistent, da alter Block bis zum Pointer-Swap gültig bleibt
Snapshots	nicht nativ (nur via LVM darunter)	nativ, quasi kostenlos
Checksummen pro Block	nein	ja (Standard)

Merksatz: CoW = nie überschreiben, immer umbiegen (btrfs/ZFS) vs. Journaling = überschreiben, aber Absicht vorher protokollieren (ext4/XFS).

Wachsen und Schrumpfen

	ext4	XFS
Online Grow	ja (`resize2fs`)	ja (`xfs_growfs`)
Offline Grow	ja	ja
Shrink	ja, aber nur offline (`resize2fs`)	nicht unterstützt

Praktisch bedeutet das: einmal als XFS formatiert und zu groß gewachsen, gibt es nur den Weg über Backup → neu formatieren → restore. Kein `xfs_shrink`.

# Online-Grow-Beispiel (LVM darunter vorausgesetzt)
lvextend -L +10G /dev/vgdata/lvwww
xfs_growfs /pfad/zum/mountpoint

Wann XFS, wann ext4?

XFS bevorzugen bei

sehr großen Volumes (Multi-TB, Datenbanken, Fileserver)
hoher paralleler I/O-Last (mehrere Prozesse schreiben gleichzeitig)
großen Dateien mit sequentiellem Zugriff

ext4 bevorzugen bei

kleineren Partitionen, wo Shrink-Flexibilität gebraucht wird
Systemen mit geringerem RAM/Overhead-Anspruch
didaktisch: um `resize2fs`-Offline-Shrink zu demonstrieren (siehe ns-Rechner im Rocky-Kurs)