# XFS Deep Dive: Das Kraftpaket für Enterprise-Daten

TL;DR / Management Summary XFS ist seit RHEL 7 das Standard-Dateisystem der Red Hat Familie. Es wurde ursprünglich von Silicon Graphics (SGI) für High-End-Server entwickelt und ist auf extreme Skalierbarkeit (Petabyte-Bereich) und parallele I/O-Zugriffe optimiert. Ein Senior Admin muss wissen: XFS ist unschlagbar schnell beim Schreiben großer Mengen, kann aber im Gegensatz zu Ext4 nicht verkleinert werden.

# 1. Einführung & Architektur

Allocation Groups und Journaling.

XFS nutzt ein konsequentes B-Baum-Design für alle Metadaten. Ein entscheidendes Feature sind die Allocation Groups (AG).

# Architektur-Übersicht (Mermaid)

graph TD
    A[XFS Partition] --> B[Allocation Group 0]
    A --> C[Allocation Group 1]
    A --> D[Allocation Group N]
    B --> E[Superblock / Inodes / Free Space]
    F[Kernel: Parallel I/O] --> B
    F --> C
    F --> D
    G[Journal / Intent Logging] --> A

• Allocation Groups: Erlauben es dem Kernel, gleichzeitig auf verschiedene Bereiche der Disk zu schreiben (Locking-Minimierung).
• Journaling: Schützt die Dateisystem-Metadaten vor Korruption bei Stromausfällen.

# 2. Erstellung & Konfiguration

Optimiert für die Hardware.

# XFS formatieren

Normalerweise erkennt XFS die Geometrie der Disk (Stripes, Blocks) automatisch.

sudo mkfs.xfs /dev/sdb1

# Mount-Optionen für Performance

In der /etc/fstab nutzen wir meist defaults. Aber für High-Load Server:

• noatime: Deaktiviert das Schreiben des Zugriffszeitstempels (spart I/O).
• logbsize: Erhöht den In-Memory Journal Puffer (z.B. 256k).

# Beispiel fstab
UUID=xxx /data xfs defaults,noatime,logbsize=256k 0 0

# 3. Day-2 Operations: Wartung & Resizing

Im laufenden Betrieb skalieren.

# Online Vergrößern (Online Resize)

XFS kann vergrößert werden, während das Dateisystem gemountet ist.

# 1. LV vergrößern (siehe Artikel 020)
sudo lvextend -L +100G /dev/vg_data/lv_data

# 2. XFS informieren (Pfad ist der MOUNTPOINT!)
sudo xfs_growfs /mnt/data

# Integrität prüfen (Repair)

XFS führt beim Booten kein klassisches fsck durch. Wenn Fehler auftreten:

# Prüfen & Reparieren (Nur ungemountet!)
sudo xfs_repair /dev/sdb1

# 4. Troubleshooting & “War Stories”

Wenn die Metadaten hängen.

# Story 1: “Der Shrink-Wunsch”

Symptom: Ein Kunde will von 10TB auf 500GB reduzieren, um Kosten in der Cloud zu sparen. Ursache: Das Dateisystem ist XFS. Lösung: Backup & Restore. Es gibt keinen Weg, XFS zu verkleinern. Lektion: Nutzen Sie bei unsicheren Größen-Planungen LVM-Thin-Provisioning oder Ext4.

# Story 2: “Corrupt Metadata”

Symptom: Der Server bootet, bricht aber mit “Structure needs cleaning” beim Mounten ab. Ursache: Harter Power-Off während massiver Metadaten-Operationen. Lösung: Nutzen Sie xfs_repair -L. Das -L löscht das Journal (Log). Es kann zu minimalem Datenverlust der letzten Sekunden kommen, stellt aber die Konsistenz des Dateisystems wieder her.

# 5. Performance & Benchmarking

Verwenden Sie xfs_info, um die Geometrie zu prüfen:

sudo xfs_info /mnt/data

Achten Sie auf agcount. Bei sehr vielen Kernen und massiver Parallelität sollte dieser Wert hoch sein.

# 6. Fazit & Empfehlung

• Database & Big Data: XFS ist die erste Wahl.
• Root Partition: Perfekt, da es extrem robust ist.
• Wichtig: Sichern Sie Ihre Daten! Die Unfähigkeit zu “Shrinken” macht XFS unflexibel bei Fehlplanungen.

# Anhang: Cheatsheet