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

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)

xfs Handling

XFS – Administration in der Praxis

Die wichtigsten Kommandos für den täglichen Umgang mit XFS-Dateisystemen auf RHEL/Rocky-Systemen.

Dateisystem anlegen

Einfaches Anlegen

• mkfs.xfs /dev/sdb2

Mit Label und erzwungenem Überschreiben

• mkfs.xfs -f -L test /dev/sda4
  • -f erzwingt das Anlegen, auch wenn bereits ein Dateisystem existiert
  • -L setzt ein Label (max. 12 Zeichen)

meta-data=/dev/sdb2              isize=512    agcount=4, agsize=327680 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=1310720, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

• Erläuterung der Ausgabe von `xfs_info /dev/sdb2`, Zeile für Zeile

Dateisystem-Informationen abrufen

Metadaten und Aufbau anzeigen

• xfs_info /dev/sda4
• oder auf einem gemounteten Filesystem: xfs_info /pfad/zum/mountpoint

Label oder UUID prüfen

• lsblk -f

Online vergrößern (Grow)

Voraussetzung: das darunterliegende Blockdevice bzw. der LV wurde bereits vergrößert (z. B. lvextend).

• xfs_growfs /pfad/zum/mountpoint

Wichtig

• xfs_growfs arbeitet immer auf dem Mountpoint, nicht auf dem Device selbst – anders als resize2fs bei ext4
• Ein Shrink ist bei XFS nicht möglich, weder online noch offline

Reparieren

• Nur im ungemounteten Zustand ausführen
• xfs_repair /dev/sdb2

Bei beschädigtem Log

• xfs_repair -L /dev/sdb2
  • Log wird verworfen, Datenverlust möglich – nur als letzten Ausweg nutzen, wenn ein normaler Log-Replay beim Mount fehlschlägt

Label oder UUID nachträglich ändern

Ohne Neuformatierung, nur im ungemounteten Zustand:

• xfs_admin -L neuesLabel /dev/sdb2
• xfs_admin -U generate /dev/sdb2

Fragmentierung

Grad der Fragmentierung prüfen

• xfs_db -c frag -r /dev/sdXn

Defragmentieren

• xfs_fsr /dev/sdb2
• Ohne Geräteangabe durchsucht xfs_fsr alle gemounteten XFS-Dateisysteme aus /etc/mtab

Freeze/Unfreeze

Für konsistente Snapshots eines laufenden Systems (z. B. vor einem LVM-Snapshot):

• xfs_freeze -f /pfad/zum/mountpoint
• xfs_freeze -u /pfad/zum/mountpoint

Quota

Aktivierung über Mount-Option in /etc/fstab

• uquota (User-Quota), gquota (Group-Quota) oder pquota (Project-Quota)

Auswertung

• xfs_quota -x -c 'report' /pfad/zum/mountpoint