Xfs

XFS ist ein 64-Bit-Journaling-Dateisystem, ursprünglich von Silicon Graphics (SGI) in den 1990er Jahren für IRIX und High-Performance-Computing entwickelt, seit 2001 für Linux verfügbar und seit Kernel 2.6 fester Bestandteil des offiziellen Kernels. Auf Red Hat, Rocky und CentOS ist es das Standard-Dateisystem. Dieser Artikel behandelt Aufbau und Besonderheiten von XFS sowie die Werkzeuge zur Administration.

Alle Beispiele verwenden Datenpartitionen ab /dev/sdb. /dev/sda ist die Systemplatte und wird nie angefasst.

Animation zum Durchklicken: XFS in der Praxis

Eigenschaften von XFS

Kerncharakteristik

• Journaling-Dateisystem – kein Copy-on-Write wie btrfs oder ZFS.
• Aufbau in unabhängigen Allocation Groups (AGs) statt klassischer Block Groups.
• Online-Vergrößern möglich, Verkleinern praktisch nicht (siehe Wachsen und Schrumpfen).
• Sehr gute Skalierung bei großen Dateien und hoher Parallelität, ausgelegt bis in den Exabyte-Bereich.

Erweiterte Funktionen

• ACLs (Access Control Lists), erweiterte Attribute (xattr) und Quota-Unterstützung (User, Group, Project).

Architektur

Auch ext4 unterteilt das Volume in Gruppen. Der Unterschied liegt nicht in der Gruppierung selbst, sondern in Zweck und Locking-Granularität:

• Ext4 Block Groups dienen vor allem der Lokalität – Inodes nah bei ihren Datenblöcken, kurze Seek-Wege auf HDDs. Parallelität war nicht das Entwurfsziel; Journal und viele Strukturen sind global.
• XFS Allocation Groups sind für echte Parallelität entworfen – praktisch unabhängige Mini-Dateisysteme innerhalb eines Geräts. Jede AG verwaltet ihren freien Platz und ihre Inodes selbst und hat eigene AGF/AGI-Locks, sodass mehrere Threads gleichzeitig in verschiedenen AGs allozieren können, ohne sich zu blockieren.

Merksatz: Beide haben Gruppen – ext4 nutzt sie vor allem für Lokalität, XFS für Locking-Granularität und damit für Parallelität.

Abbildung 1: Aufbau der Allocation Groups

Die zentralen Metadaten-Strukturen

• Superblock – nur in AG 0 der echte Superblock, in allen weiteren AGs eine Kopie zur Redundanz. Enthält die globalen Parameter: Blockgröße, AG-Größe, Inode-Größe, UUID.
• AGF (Allocation Group Free Space) – verwaltet den freien Platz innerhalb der AG über zwei parallele B+Trees: einer sortiert nach Blocknummer (Suche nach freiem Extent nahe bestehender Daten), einer nach Extent-Größe (passenden freien Extent für eine Allokation finden).
• AGI (Allocation Group Inode Information) – verwaltet Inodes ohne feste Bitmap, dynamisch per B+Tree. Deshalb ist die Zahl der Inodes bei XFS – anders als bei ext4 – beim mkfs nicht fest vorgegeben, sondern wächst mit Bedarf. Begrenzt wird sie nur durch imaxpct: höchstens so viel Prozent des Platzes dürfen Inodes belegen (Vorgabe 25 %, sichtbar in der mkfs-Ausgabe).
• B+Trees – XFS verwendet fast überall B+Trees statt linearer Bitmaps (Free Space, Inodes, Extents, große Verzeichnisse). Suchen, Einfügen und Löschen laufen in O(log n) statt linearem Scan.

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 die Platte. Dadurch werden viele kleine Schreibvorgänge zu einem großen zusammenhängenden Extent zusammengefasst – weniger Fragmentierung bei sequentiellen Lasten wie Datenbank-Dumps, Logs oder großen Kopien.

Abbildung 2: Delayed Allocation

Delayed Allocation ist kein XFS-Alleinstellungsmerkmal – ext4 nutzt dasselbe Prinzip (siehe ext4 Eigenschaften).

XFS ist kein Copy-on-Write

Im normalen Betrieb überschreibt XFS Blöcke an Ort und Stelle. Eine Ausnahme sind Reflinks (reflink=1 in der mkfs-Ausgabe): cp --reflink legt eine Kopie an, die sich die Blöcke mit dem Original teilt. Erst wenn eine der beiden Dateien geändert wird, schreibt XFS den betroffenen Block neu – nur für diese geteilten Blöcke arbeitet XFS also Copy-on-Write. Snapshots eines ganzen Dateisystems entstehen daraus nicht.

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

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

Wachsen und Schrumpfen

	ext4	XFS
Online vergrößern	ja (resize2fs)	ja (xfs_growfs)
Offline vergrößern	ja	ja
Verkleinern	ja, aber nur offline	praktisch nicht

Einmal als XFS formatiert und zu groß gewachsen, gibt es nur den Weg über Backup, Neuformatieren und Restore. Ein xfs_shrink existiert nicht. Neuere Kernel können mit xfs_growfs -D zwar ungenutzten Platz am Ende der letzten Allocation Group abschneiden, das ist aber experimentell und hilft fast nie: Ganze AGs lassen sich nicht entfernen.

Wann XFS, wann ext4?

• XFS bei sehr großen Volumes (Multi-TB, Datenbanken, Fileserver), hoher paralleler I/O-Last und großen Dateien mit sequentiellem Zugriff.
• ext4 bei kleineren Partitionen, wo man Verkleinern braucht, bei geringerem RAM-/Overhead-Anspruch und didaktisch, um den Offline-Shrink mit resize2fs zu zeigen.

Administration

Die folgenden Werkzeuge gehören zum täglichen Umgang mit XFS auf RHEL/Rocky.

Ein Dateisystem anlegen

• mkfs.xfs /dev/sdb2

Mit Label und erzwungenem Überschreiben. -f legt auch dann an, wenn schon ein Dateisystem existiert; -L setzt ein Label (max. 12 Zeichen).

• mkfs.xfs -f -L test /dev/sdb2

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

In der Ausgabe sieht man agcount=4: vier Allocation Groups. Das Journal (log) liegt intern im Dateisystem selbst.

Informationen abrufen

Metadaten und Aufbau anzeigen – wahlweise über das Gerät oder über den Mountpunkt.

• xfs_info /dev/sdb2

Label und UUID aller Blockgeräte:

• lsblk -f

Online vergrößern

Voraussetzung: das darunterliegende Blockgerät wurde bereits vergrößert – der Logical Volume oder die Partition. Wichtig: xfs_growfs arbeitet auf dem Mountpunkt, nicht auf dem Gerät – anders als resize2fs bei ext4. Das Dateisystem muss dafür gemountet sein.

Variante 1: auf LVM

• lvextend -L +5G /dev/vg0/daten
• xfs_growfs /mnt/work

Oder beides in einem Schritt (-r ruft das passende Werkzeug zum Vergrößern selbst auf):

• lvextend -r -L +5G /dev/vg0/daten

Variante 2: auf einer Partition

Hinter der Partition muss freier Platz auf der Platte sein. Am einfachsten vergrößert growpart (Paket cloud-utils-growpart) die Partition, ohne den Startsektor zu verändern.

• df -h /mnt/work
• growpart /dev/sdc 1
• xfs_growfs /mnt/work
• df -h /mnt/work

Von Hand mit gdisk geht es auch: Partition löschen und mit demselben Startsektor größer neu anlegen, vorhandene Dateisystem-Signaturen dabei nicht löschen lassen, danach den Kernel mit partprobe /dev/sdc informieren. Ein anderer Startsektor zerstört das Dateisystem.

Reparieren

Nur im ausgehängten Zustand.

• umount /mnt/work

• xfs_repair /dev/sdb2

Erst prüfen, ohne etwas zu ändern:

• xfs_repair -n /dev/sdb2

Ist das Log nicht leer, verweigert xfs_repair die Arbeit. Dann zuerst einmal mounten und wieder aushängen – beim Mounten spielt XFS das Log ab. Erst wenn das scheitert, verwirft man das Log mit -L. Datenverlust möglich – nur als letzter Ausweg.

• xfs_repair -L /dev/sdb2

Label oder UUID nachträglich ändern

Ohne Neuformatieren, nur im ausgehängten 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/sdb2

Der ausgegebene Fragmentierungsfaktor sieht oft erschreckend hoch aus, sagt aber wenig: Schon wenige Dateien mit zwei Extents treiben ihn nach oben. Aussagekräftiger ist der Blick auf einzelne Dateien mit xfs_bmap -v datei oder filefrag -v datei.

Defragmentieren. xfs_fsr arbeitet nur auf gemounteten Dateisystemen; ohne Angabe durchsucht es alle gemounteten XFS-Dateisysteme.

• xfs_fsr /dev/sdb2

Freeze und Unfreeze

Hält alle Schreibzugriffe an und bringt das Dateisystem in einen konsistenten Zustand, etwa für einen Snapshot im Speichersystem oder auf Hypervisor-Ebene. lvcreate --snapshot friert das Dateisystem selbst ein, dafür ist der Befehl nicht nötig. Solange es eingefroren ist, hängen alle Prozesse, die schreiben wollen – also nicht vergessen, wieder aufzutauen. Einfrieren:

• xfs_freeze -f /mnt/work

Wieder auftauen:

• xfs_freeze -u /mnt/work

Quota

Quota wird über eine Mount-Option in /etc/fstab aktiviert: uquota (User), gquota (Group) oder pquota (Project). Ein mount -o remount reicht dafür nicht, das Dateisystem muss neu eingehängt werden; für das Root-Dateisystem gehört die Option als rootflags= auf die Kernel-Kommandozeile. Auswertung:

• xfs_quota -x -c 'report' /mnt/work

Aufgaben

Vorbereitung: Auf /dev/sdc müssen drei Partitionen angelegt sein (/dev/sdc1 bis /dev/sdc3). Falls nicht, zuerst mit gdisk anlegen. Wichtig: immer die Partition ansprechen, nie die ganze Platte – und /dev/sda bleibt als Systemplatte unangetastet.

Dateisysteme anlegen

• Legen Sie auf der 1. Partition von /dev/sdc ein XFS-Dateisystem an.

• Legen Sie auf der 2. Partition ein XFS-Dateisystem mit dem Label "archiv" an.

• Legen Sie auf der 3. Partition ein XFS-Dateisystem an und überschreiben Sie dabei ein eventuell vorhandenes Dateisystem.

• Lesen Sie aus der mkfs-Ausgabe ab, wie viele Allocation Groups angelegt wurden.

Informationen abrufen

• Lassen Sie sich die Metadaten der 1. Partition anzeigen.

• Zeigen Sie Label und UUID aller Blockgeräte an und prüfen Sie, ob das Label "archiv" auf der 2. Partition gesetzt ist.

• Hängen Sie die 2. Partition unter /mnt/work ein und lassen Sie sich die Metadaten über den Mountpunkt anzeigen.

Label und UUID ändern

Hinweis: xfs_admin arbeitet nur am ausgehängten Dateisystem.

• Hängen Sie die 2. Partition wieder aus und ändern Sie ihr Label auf "daten".

• Vergeben Sie für die 2. Partition eine neue, zufällige UUID.

• Kontrollieren Sie das Ergebnis.

Prüfen und reparieren

Hinweis: xfs_repair nur auf ausgehängten Partitionen ausführen.

• Prüfen Sie die 1. Partition, ohne Änderungen vorzunehmen.

• Führen Sie eine Reparatur der 1. Partition durch.

• Was tut xfs_repair -L, und warum ist das der letzte Ausweg?

Fragmentierung

• Ermitteln Sie den Fragmentierungsgrad der 3. Partition.

• Hängen Sie die 3. Partition unter /mnt/work ein und defragmentieren Sie das Dateisystem.

Freeze und Unfreeze

• Frieren Sie das unter /mnt/work eingehängte Dateisystem ein und versuchen Sie in einem zweiten Terminal, eine Datei anzulegen.

• Tauen Sie es wieder auf.

Zum Nachdenken

• Sie haben ein XFS-Dateisystem zu groß angelegt und wollen es verkleinern. Wie gehen Sie vor?

• Auf welchem der beiden Wege spricht man xfs_growfs an – über das Gerät oder über den Mountpunkt?