Xfs: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
−
=xfs Grundsätzliches=
+
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 und seit 2001 im Linux-Kernel. Auf Red Hat, Rocky und CentOS ist es das Standard-Dateisystem. Dieser Artikel behandelt Aufbau und Besonderheiten von XFS sowie die Werkzeuge zur Administration.
−
== Was ist XFS? ==
 
  
−
*XFS ist ein 64-Bit-Journaling-Dateisystem für UNIX-ähnliche Betriebssysteme, entwickelt von Silicon Graphics Inc. (SGI).
+
Alle Beispiele verwenden Datenpartitionen ab <code>/dev/sdb</code>. '''<code>/dev/sda</code> ist die Systemplatte und wird nie angefasst.'''
−
*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
+
=Eigenschaften von XFS=
−
*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
+
==Kerncharakteristik==
−
*ACLs (Access Control Lists)
+
*Journaling-Dateisystem – kein Copy-on-Write wie btrfs oder ZFS.
−
*Erweiterte Attribute (xattr)
+
*Aufbau in unabhängigen '''Allocation Groups (AGs)''' statt klassischer Block Groups.
−
*Quota-Unterstützung
+
*Online-Vergrößern möglich, '''Verkleinern nicht''' – weder online noch offline.
 +
*Sehr gute Skalierung bei großen Dateien und hoher Parallelität, ausgelegt bis in den Exabyte-Bereich.
  
−
== Architektur-Überblick ==
+
==Erweiterte Funktionen==
 +
*ACLs (Access Control Lists), erweiterte Attribute (xattr) und Quota-Unterstützung (User, Group, Project).
  
−
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''':
+
=Architektur=
  
−
;Ext4 Block Groups
+
Auch ext4 unterteilt das Volume in Gruppen. Der Unterschied liegt nicht in der Gruppierung selbst, sondern in Zweck und Locking-Granularität:
−
*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)
+
*'''Ext4 Block Groups''' dienen vor allem der '''Lokalität''' – Inodes nah bei ihren Datenblöcken, kurze Seek-Wege auf HDDs. Die Allokation läuft faktisch über einen globalen, seriell arbeitenden Allocator.
−
*Für echte '''Parallelität''' designed – praktisch unabhängige Mini-Dateisysteme innerhalb eines Devices
+
*'''XFS Allocation Groups''' sind für echte '''Parallelität''' entworfen – praktisch unabhängige Mini-Dateisysteme innerhalb eines Geräts. Jede AG hat eigene AGF/AGI-Locks, sodass mehrere Threads gleichzeitig in verschiedenen AGs allozieren können, ohne sich zu blockieren.
−
*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).
+
'''Merksatz:''' Beide haben Gruppen – ext4 nutzt sie für Lokalität (seriell), XFS für Locking-Granularität (parallel).
  
−
<pre>
+
{{#drawio:xfs-ag}}
−
+------------------------------------------------------------+
+
''Abbildung 1: Aufbau der Allocation Groups''
−
|                    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.  | |
 
−
|  +-----------+  +-----------+  +-----------+  +-----------+ |
 
−
+------------------------------------------------------------+
 
−
</pre>
 
  
−
=== Mermaid-Diagramm: Struktur einer Allocation Group ===
+
==Die zentralen Metadaten-Strukturen==
  
−
<mermaid>
+
*'''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.
−
graph TD
+
*'''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).
−
    FS[XFS Volume] --> AG0[Allocation Group 0]
+
*'''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 <code>mkfs</code> '''nicht''' fest vorgegeben, sondern wächst mit Bedarf.
−
    FS --> AG1[Allocation Group 1]
+
*'''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.
−
    FS --> AGN[Allocation Group N ...]
 
  
−
    AG0 --> SB[Superblock - primär]
+
=Delayed Allocation=
−
    AG0 --> AGF0[AGF - Free Space B+Trees]
 
−
    AG0 --> AGI0[AGI - Inode B+Tree]
 
−
    AG0 --> IN0[Inodes]
 
−
    AG0 --> DB0[Datenblöcke]
 
  
−
    AG1 --> SB1[Superblock - Kopie]
+
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.
−
    AG1 --> AGF1[AGF]
 
−
    AG1 --> AGI1[AGI]
 
−
    AG1 --> IN1[Inodes]
 
−
    AG1 --> DB1[Datenblöcke]
 
−
</mermaid>
 
  
−
== Die zentralen Metadaten-Strukturen ==
+
{{#drawio:xfs-delalloc}}
 +
''Abbildung 2: Delayed Allocation''
  
−
;Superblock
+
Delayed Allocation ist kein XFS-Alleinstellungsmerkmal – ext4 nutzt dasselbe Prinzip (siehe [[ext4 Eigenschaften]]).
−
*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)
+
=XFS ist kein Copy-on-Write=
−
*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 ==
 
  
 
{| class="wikitable"
 
{| class="wikitable"
Zeile 116: Zeile 49:
 
| Schreibprinzip || Overwrite in-place || Copy-on-Write
 
| 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
+
| Crash-Konsistenz || Metadaten-Journal (Redo/Replay) || alter Block bleibt bis zum Pointer-Swap gültig
 
|-
 
|-
−
| Snapshots || nicht nativ (nur via LVM darunter) || nativ, quasi kostenlos
+
| Snapshots || nicht nativ (nur über LVM darunter) || nativ, quasi kostenlos
 
|-
 
|-
−
| Checksummen pro Block || nein || ja (Standard)
+
| Prüfsummen je Block || nein (nur Metadaten) || ja (Standard)
 
|}
 
|}
  
−
'''Merksatz:''' CoW = nie überschreiben, immer umbiegen (btrfs/ZFS) vs. Journaling = überschreiben, aber Absicht vorher protokollieren (ext4/XFS).
+
'''Merksatz:''' CoW = nie überschreiben, immer umbiegen (btrfs/ZFS). Journaling = überschreiben, aber die Absicht vorher protokollieren (ext4/XFS).
  
−
== Wachsen und Schrumpfen ==
+
=Wachsen und Schrumpfen=
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! !! ext4 !! XFS
 
! !! ext4 !! XFS
 
|-
 
|-
−
| Online Grow || ja (`resize2fs`) || ja (`xfs_growfs`)
+
| Online vergrößern || ja (<code>resize2fs</code>) || ja (<code>xfs_growfs</code>)
 
|-
 
|-
−
| Offline Grow || ja || ja
+
| Offline vergrößern || ja || ja
 
|-
 
|-
−
| Shrink || ja, aber nur offline (`resize2fs`) || '''nicht unterstützt'''
+
| Verkleinern || ja, aber nur offline || '''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`.
+
Einmal als XFS formatiert und zu groß gewachsen, gibt es nur den Weg über Backup, Neuformatieren und Restore. Ein <code>xfs_shrink</code> existiert nicht.
 +
 
 +
=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 <code>resize2fs</code> 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. <code>-f</code> legt auch dann an, wenn schon ein Dateisystem existiert; <code>-L</code> 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 <code>agcount=4</code>: vier Allocation Groups. Das Journal (<code>log</code>) 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 oder der LV wurde bereits vergrößert (etwa mit <code>lvextend</code>). Wichtig: <code>xfs_growfs</code> arbeitet auf dem '''Mountpunkt''', nicht auf dem Gerät – anders als <code>resize2fs</code> bei ext4.
 +
*xfs_growfs /mnt/work
 +
 
 +
==Reparieren==
 +
Nur im '''ausgehängten''' Zustand.
 +
*umount /mnt/work
 +
 
 +
*xfs_repair /dev/sdb2
 +
 
 +
Bei beschädigtem Log wird es mit <code>-L</code> verworfen. Datenverlust möglich – nur als letzter Ausweg, wenn der normale Log-Replay beim Mounten fehlschlägt.
 +
*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
  
−
<syntaxhighlight lang="bash">
+
Defragmentieren. Ohne Geräteangabe durchsucht <code>xfs_fsr</code> alle gemounteten XFS-Dateisysteme.
−
# Online-Grow-Beispiel (LVM darunter vorausgesetzt)
+
*xfs_fsr /dev/sdb2
−
lvextend -L +10G /dev/vgdata/lvwww
 
−
xfs_growfs /pfad/zum/mountpoint
 
−
</syntaxhighlight>
 
  
−
== Wann XFS, wann ext4? ==
+
==Freeze und Unfreeze==
 +
Für einen konsistenten Snapshot eines laufenden Systems, etwa vor einem LVM-Snapshot. Einfrieren:
 +
*xfs_freeze -f /mnt/work
  
−
;XFS bevorzugen bei
+
Wieder auftauen:
−
*sehr großen Volumes (Multi-TB, Datenbanken, Fileserver)
+
*xfs_freeze -u /mnt/work
−
*hoher paralleler I/O-Last (mehrere Prozesse schreiben gleichzeitig)
 
−
*großen Dateien mit sequentiellem Zugriff
 
  
−
;ext4 bevorzugen bei
+
==Quota==
−
*kleineren Partitionen, wo Shrink-Flexibilität gebraucht wird
+
Quota wird über eine Mount-Option in <code>/etc/fstab</code> aktiviert: <code>uquota</code> (User), <code>gquota</code> (Group) oder <code>pquota</code> (Project). Auswertung:
−
*Systemen mit geringerem RAM/Overhead-Anspruch
+
*xfs_quota -x -c 'report' /mnt/work
−
*didaktisch: um `resize2fs`-Offline-Shrink zu demonstrieren (siehe ns-Rechner im Rocky-Kurs)
 
  
−
[[Kategorie:Dateisysteme]]
+
=Aufgaben=
−
[[Kategorie:Rocky Linux Kurs]]
 
  
−
=xfs Handling=
+
Vorbereitung: Auf <code>/dev/sdc</code> müssen drei Partitionen angelegt sein (<code>/dev/sdc1</code> bis <code>/dev/sdc3</code>). Falls nicht, zuerst mit <code>gdisk</code> anlegen. '''Wichtig:''' immer die Partition ansprechen, nie die ganze Platte – und <code>/dev/sda</code> bleibt als Systemplatte unangetastet.
−
== XFS – Administration in der Praxis ==
 
  
−
Die wichtigsten Kommandos für den täglichen Umgang mit XFS-Dateisystemen auf RHEL/Rocky-Systemen.
+
==Dateisysteme anlegen==
  
−
== Dateisystem anlegen ==
+
* Legen Sie auf der 1. Partition von /dev/sdc ein XFS-Dateisystem an.
 +
<!-- Lösung: mkfs.xfs /dev/sdc1 -->
  
−
;Einfaches Anlegen
+
* Legen Sie auf der 2. Partition ein XFS-Dateisystem mit dem Label "archiv" an.
−
*<code>mkfs.xfs /dev/sdb2</code>
+
<!-- Lösung: mkfs.xfs -L archiv /dev/sdc2 -->
  
−
;Mit Label und erzwungenem Überschreiben
+
* Legen Sie auf der 3. Partition ein XFS-Dateisystem an und überschreiben Sie dabei ein eventuell vorhandenes Dateisystem.
−
*<code>mkfs.xfs -f -L test /dev/sda4</code>
+
<!-- Lösung: mkfs.xfs -f /dev/sdc3 -->
−
**<code>-f</code> erzwingt das Anlegen, auch wenn bereits ein Dateisystem existiert
 
−
**<code>-L</code> setzt ein Label (max. 12 Zeichen)
 
  
−
<pre>
+
* Lesen Sie aus der mkfs-Ausgabe ab, wie viele Allocation Groups angelegt wurden.
−
meta-data=/dev/sdb2              isize=512    agcount=4, agsize=327680 blks
+
<!-- Lösung: in der Zeile meta-data=... der Wert agcount= -->
−
        =                      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
 
−
</pre>
 
  
−
*[[Erläuterung der Ausgabe von `xfs_info /dev/sdb2`, Zeile für Zeile]]
+
==Informationen abrufen==
  
−
== Dateisystem-Informationen abrufen ==
+
* Lassen Sie sich die Metadaten der 1. Partition anzeigen.
 +
<!-- Lösung: xfs_info /dev/sdc1 -->
  
−
;Metadaten und Aufbau anzeigen
+
* Zeigen Sie Label und UUID aller Blockgeräte an und prüfen Sie, ob das Label "archiv" auf der 2. Partition gesetzt ist.
−
*<code>xfs_info /dev/sda4</code>
+
<!-- Lösung: lsblk -f -->
−
*oder auf einem gemounteten Filesystem: <code>xfs_info /pfad/zum/mountpoint</code>
 
  
−
;Label oder UUID prüfen
+
* Hängen Sie die 2. Partition unter /mnt/work ein und lassen Sie sich die Metadaten über den Mountpunkt anzeigen.
−
*<code>lsblk -f</code>
+
<!-- Lösung: mkdir -p /mnt/work; mount /dev/sdc2 /mnt/work; xfs_info /mnt/work -->
  
−
== Online vergrößern (Grow) ==
+
==Label und UUID ändern==
  
−
Voraussetzung: das darunterliegende Blockdevice bzw. der LV wurde bereits vergrößert (z. B. <code>lvextend</code>).
+
Hinweis: <code>xfs_admin</code> arbeitet nur am ausgehängten Dateisystem.
  
−
*<code>xfs_growfs /pfad/zum/mountpoint</code>
+
* Hängen Sie die 2. Partition wieder aus und ändern Sie ihr Label auf "daten".
 +
<!-- Lösung: umount /mnt/work; xfs_admin -L daten /dev/sdc2 -->
  
−
;Wichtig
+
* Vergeben Sie für die 2. Partition eine neue, zufällige UUID.
−
*<code>xfs_growfs</code> arbeitet immer auf dem '''Mountpoint''', nicht auf dem Device selbst – anders als <code>resize2fs</code> bei ext4
+
<!-- Lösung: xfs_admin -U generate /dev/sdc2 -->
−
*Ein Shrink ist bei XFS '''nicht''' möglich, weder online noch offline
 
  
−
== Reparieren ==
+
* Kontrollieren Sie das Ergebnis.
 +
<!-- Lösung: lsblk -f /dev/sdc2 -->
  
−
*Nur im '''ungemounteten''' Zustand ausführen
+
==Prüfen und reparieren==
−
*<code>xfs_repair /dev/sdb2</code>
 
  
−
;Bei beschädigtem Log
+
Hinweis: <code>xfs_repair</code> nur auf ausgehängten Partitionen ausführen.
−
*<code>xfs_repair -L /dev/sdb2</code>
 
−
**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 ==
+
* Prüfen Sie die 1. Partition, ohne Änderungen vorzunehmen.
 +
<!-- Lösung: xfs_repair -n /dev/sdc1 -->
  
−
Ohne Neuformatierung, nur im ungemounteten Zustand:
+
* Führen Sie eine Reparatur der 1. Partition durch.
 +
<!-- Lösung: xfs_repair /dev/sdc1 -->
  
−
*<code>xfs_admin -L neuesLabel /dev/sdb2</code>
+
* Was tut <code>xfs_repair -L</code>, und warum ist das der letzte Ausweg?
−
*<code>xfs_admin -U generate /dev/sdb2</code>
+
<!-- Lösung: verwirft das Log ohne Replay; die darin protokollierten, noch nicht geschriebenen Metadaten-Änderungen gehen verloren -->
  
−
== Fragmentierung ==
+
==Fragmentierung==
  
−
;Grad der Fragmentierung prüfen
+
* Ermitteln Sie den Fragmentierungsgrad der 3. Partition.
−
*<code>xfs_db -c frag -r /dev/sdXn</code>
+
<!-- Lösung: xfs_db -c frag -r /dev/sdc3 -->
  
−
;Defragmentieren
+
* Defragmentieren Sie das Dateisystem.
−
*<code>xfs_fsr /dev/sdb2</code>
+
<!-- Lösung: xfs_fsr /dev/sdc3 -->
−
*Ohne Geräteangabe durchsucht <code>xfs_fsr</code> alle gemounteten XFS-Dateisysteme aus <code>/etc/mtab</code>
 
  
−
== Freeze/Unfreeze ==
+
==Freeze und Unfreeze==
  
−
Für konsistente Snapshots eines laufenden Systems (z. B. vor einem LVM-Snapshot):
+
* Hängen Sie die 3. Partition unter /mnt/work ein und frieren Sie das Dateisystem ein.
 +
<!-- Lösung: mount /dev/sdc3 /mnt/work; xfs_freeze -f /mnt/work -->
  
−
*<code>xfs_freeze -f /pfad/zum/mountpoint</code>
+
* Tauen Sie es wieder auf.
−
*<code>xfs_freeze -u /pfad/zum/mountpoint</code>
+
<!-- Lösung: xfs_freeze -u /mnt/work -->
  
−
== Quota ==
+
==Zum Nachdenken==
  
−
;Aktivierung über Mount-Option in /etc/fstab
+
* Sie haben ein XFS-Dateisystem zu groß angelegt und wollen es verkleinern. Wie gehen Sie vor?
−
*<code>uquota</code> (User-Quota), <code>gquota</code> (Group-Quota) oder <code>pquota</code> (Project-Quota)
+
<!-- Lösung: gar nicht - XFS kennt kein Verkleinern, ein xfs_shrink existiert nicht. Einziger Weg: Backup, neu anlegen, Restore. -->
  
−
;Auswertung
+
* Auf welchem der beiden Wege spricht man xfs_growfs an – über das Gerät oder über den Mountpunkt?
−
*<code>xfs_quota -x -c 'report' /pfad/zum/mountpoint</code>
+
<!-- Lösung: über den Mountpunkt, anders als resize2fs bei ext4 -->
  
 
[[Kategorie:Dateisysteme]]
 
[[Kategorie:Dateisysteme]]
 
[[Kategorie:Rocky Linux Kurs]]
 
[[Kategorie:Rocky Linux Kurs]]

Aktuelle Version vom 24. August 2026, 14:04 Uhr

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 und seit 2001 im Linux-Kernel. 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.

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 nicht – weder online noch offline.
  • 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. Die Allokation läuft faktisch über einen globalen, seriell arbeitenden Allocator.
  • XFS Allocation Groups sind für echte Parallelität entworfen – praktisch unabhängige Mini-Dateisysteme innerhalb eines Geräts. Jede AG 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 für Lokalität (seriell), XFS für Locking-Granularität (parallel).

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.
  • 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

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 nicht unterstützt

Einmal als XFS formatiert und zu groß gewachsen, gibt es nur den Weg über Backup, Neuformatieren und Restore. Ein xfs_shrink existiert nicht.

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 oder der LV wurde bereits vergrößert (etwa mit lvextend). Wichtig: xfs_growfs arbeitet auf dem Mountpunkt, nicht auf dem Gerät – anders als resize2fs bei ext4.

  • xfs_growfs /mnt/work

Reparieren

Nur im ausgehängten Zustand.

  • umount /mnt/work
  • xfs_repair /dev/sdb2

Bei beschädigtem Log wird es mit -L verworfen. Datenverlust möglich – nur als letzter Ausweg, wenn der normale Log-Replay beim Mounten fehlschlägt.

  • 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

Defragmentieren. Ohne Geräteangabe durchsucht xfs_fsr alle gemounteten XFS-Dateisysteme.

  • xfs_fsr /dev/sdb2

Freeze und Unfreeze

Für einen konsistenten Snapshot eines laufenden Systems, etwa vor einem LVM-Snapshot. 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). 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.
  • Defragmentieren Sie das Dateisystem.

Freeze und Unfreeze

  • Hängen Sie die 3. Partition unter /mnt/work ein und frieren Sie das Dateisystem ein.
  • 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?
Abgerufen von „https://www.xinux.net/index.php?title=Xfs&oldid=73024“