Xfs

• xfs Grundsätzliches
• xfs Handling

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

<mermaid> 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]

</mermaid>

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.

<mermaid> 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

</mermaid>

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)