Xfs

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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

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
Abgerufen von „https://xinux.net/index.php?title=Xfs&oldid=72896“