Filesysteme

Siehe auch

Verwandte Artikel
Offizielle Dokumentation
Linuxfabrik

In Linux ist alles eine Datei (oder wird zumindest wie eine Datei behandelt), was zur Folge hat, dass man sowohl mit Dokumenten wie auch mit Geräten über die gleiche Art von Input/Output (I/O)-Operationen interagieren kann. Ein Dateisystem organisiert auf einem Block-Gerät, welche Bytes zu welcher Datei gehören, und verwaltet dazu Metadaten wie Namen, Besitzer, Zeitstempel und Rechte.

Die einzelnen Dateisysteme sind in FS: Ext4, FS: XFS und FS: Btrfs beschrieben, das Konzept der Dateisysteme im User Space in FUSE.

Konzepte und Begriffe

Inode

Der Metadaten-Eintrag einer Datei: Typ, Besitzer, Gruppe, Rechte, Zeitstempel, Grösse und die Verweise auf die Datenblöcke. Der Dateiname selbst steht nicht im Inode, sondern im Verzeichnis, das auf die Inode-Nummer zeigt. Die Zahl der Inodes begrenzt, wie viele Dateien ein Dateisystem aufnehmen kann; bei ext4 wird sie beim Anlegen fixiert, XFS und Btrfs vergeben Inodes dynamisch.

Superblock

Der zentrale Metadaten-Block eines Dateisystems mit Blockgrösse, Anzahl Blöcke und Inodes, Feature-Flags und Mount-Informationen. Geht er verloren, ist das Dateisystem unlesbar; deshalb halten die Dateisysteme Backup-Kopien vor.

Journaling

Bevor ext4 und XFS Metadaten ändern, schreiben sie die Absicht in ein Journal. Nach einem Absturz wird das Journal abgespielt, statt das gesamte Dateisystem zu prüfen. Das schützt die Konsistenz der Metadaten, nicht zwingend den Inhalt einzelner Dateien.

Extent

Ein zusammenhängender Bereich von Blöcken, der als Einheit (Start plus Länge) verwaltet wird, statt jeden Block einzeln zu adressieren. Das reduziert Fragmentierung und Metadaten-Aufwand bei grossen Dateien. ext4 und XFS sind extent-basiert.

Copy-on-Write (CoW)

Beim Ändern wird nicht der bestehende Block überschrieben, sondern eine geänderte Kopie an anderer Stelle geschrieben. Das ist die Grundlage für Snapshots ohne Vollkopie und für Datenintegrität per Prüfsumme. Der alte Block bleibt so lange belegt, wie ihn noch etwas referenziert (etwa ein Snapshot); Btrfs zählt diese Referenzen und gibt den Block erst frei, sobald die letzte wegfällt. Die Freigabe erledigt asynchron ein Hintergrund-Thread (btrfs-cleaner) nach dem nächsten Transaktions-Commit. Btrfs arbeitet durchgängig CoW; ext4 und XFS nur in Sonderfällen.

Subvolume

Ein eigenständig verwaltbarer Namensraum innerhalb eines Btrfs-Dateisystems, der sich getrennt mounten und unabhängig per Snapshot sichern lässt. ext4 und XFS kennen kein Äquivalent.

Thin Provisioning

Speicher wird einem Dateisystem erst beim tatsächlichen Schreiben zugewiesen, nicht beim Anlegen. So lässt sich mehr Platz versprechen, als physisch vorhanden ist (Overcommit). LVM-Thin und Stratis nutzen das; entsprechend muss die reale Belegung überwacht werden.

Dateisystem erstellen

Um Dateisysteme zu erstellen, benötigt man das mkfs-Kommando. Im Beispiel wird ein XFS-Dateisystem auf der Partition /dev/sdb3 eingerichtet, in zwei alternativen Schreibweisen:

mkfs --type xfs /dev/sdb3
mkfs.xfs /dev/sdb3

Andere Dateisysteme wie Ext4 werden analog dazu erstellt:

mkfs --type ext4 /dev/sdb4
mkfs.ext4 /dev/sdb4

Damit das Dateisystem genutzt werden kann, muss es in den Verzeichnisbaum eingehängt werden - man „mountet“ es, hier beispielsweise direkt über die /etc/fstab:

/etc/fstab
/dev/sdb3  /mnt/myfs1  xfs   defaults  0  0
/dev/sdb4  /mnt/myfs2  ext4  defaults  0  0

mkdir /mnt/myfs{1..2}
mount --all
df --print-type

Welches Dateisystem auf den einzelnen Partitionen verwendet wird, zeigt:

df --human-readable --print-type
mkfs.xfs: cannot open /dev/sda1: Device or resource busy?

Herausfinden, welcher Prozess die Disk verwendet. Kandidaten sind Server-Dienste, mdadm oder multipath.

lsblk
dnf install --assumeyes psmisc
fuser --verbose --mount /dev/sda1

Die Dateisysteme im Vergleich

Standardmässig verwendet RHEL seit Version 7 das XFS-Dateisystem, während bis RHEL 6 noch Ext4 das vorherrschende Dateisystem war. ACLs sind seit RHEL 5 sowohl in XFS als auch in Ext4 aktiv.

  • XFS (FS: XFS) ist der Default in RHEL und Rocky seit RHEL 7. Es skaliert sehr gut auf grosse Dateisysteme und parallele Last, lässt sich aber nur vergrössern und nicht verkleinern und kennt keine eigenen Snapshots.

  • Ext4 (FS: Ext4) ist das ältere, konservative Allround-Dateisystem. Es lässt sich online vergrössern und (ausgehängt) verkleinern und mit den vertrauten e2fsprogs-Werkzeugen prüfen und reparieren.

  • Btrfs (FS: Btrfs) bringt CoW, Subvolumes, native Snapshots, Prüfsummen, Kompression und Multi-Device mit. Es ist in RHEL und Rocky nicht enthalten (in RHEL 8 entfernt) und damit nur unter Fedora, SUSE und ähnlichen Distributionen ein Thema.

  • Stratis (Stratis) ist die RHEL-eigene Antwort auf die Btrfs-/ZFS-Ergonomie: ein verwalteter, thin-provisionierter Pool über XFS mit einfachen Snapshots, ohne dass man LVM und Dateisystem von Hand kombinieren muss.

Für Snapshots und Quotas auf ext4 und XFS spielt zusätzlich die Schicht darunter eine Rolle (LVM, siehe LVM), da diese Dateisysteme bestimmte Funktionen selbst nicht mitbringen.

LVM und Stratis

Unter dem Dateisystem sitzt oft eine Volume-Management-Schicht, die mehrere Geräte bündelt, Logical Volumes bereitstellt und Funktionen wie Snapshots oder Thin Provisioning liefert. Unter RHEL und Rocky gibt es dafür zwei Werkzeuge, die beide auf demselben Kernel-Unterbau (Device Mapper) aufsetzen, sich aber in Anspruch und Bedienung unterscheiden.

LVM (siehe LVM) richtet auch der RHEL-Installer standardmässig ein. Es fasst Block-Geräte zu Volume Groups zusammen und teilt daraus Logical Volumes zu, auf denen ein beliebiges Dateisystem liegt (ext4, XFS und andere). LVM beherrscht Striping, Mirroring und RAID, Thin Pools, Cache und Snapshots. Die Ebenen Physical Volume, Volume Group, Logical Volume und Dateisystem werden dabei einzeln angelegt und vergrössert.

Stratis (siehe Stratis) kam mit RHEL 8 dazu. Es verwaltet einen thin-provisionierten Pool aus XFS-Dateisystemen über einen Daemon und eine an ZFS und Btrfs angelehnte CLI. Stratis ersetzt LVM nicht und setzt auch nicht darauf auf, sondern nutzt Device Mapper (samt Thin-Target), XFS und LUKS direkt und fasst die einzelnen LVM-Schritte zu wenigen Kommandos zusammen.

Beide existieren parallel und decken unterschiedliche Anwendungsfälle ab. LVM unterstützt beliebige Dateisysteme sowie RAID-Level und Cache und ist nötig, wo diese gebraucht werden. Stratis deckt den Fall „lokaler Pool aus XFS-Dateisystemen mit Snapshots“ mit weniger Handgriffen ab, vergleichbar mit der Bedienung von Btrfs, das in RHEL und Rocky nicht mehr enthalten ist. LVM wird dadurch weder abgelöst noch veraltet; beide werden in aktuellen RHEL-Versionen unterstützt und gepflegt.

Btrfs (siehe FS: Btrfs) verschmilzt Volume-Management und Dateisystem zu einer Schicht und bringt Multi-Device, RAID und Snapshots selbst mit. Dort, wo es verfügbar ist (Fedora, SUSE), kann es die Kombination aus LVM und Dateisystem für viele lokale Anwendungsfälle ersetzen. In RHEL und Rocky ist das keine Option, weil Btrfs dort fehlt; genau diese Lücke füllt Stratis. Vollständig obsolet macht Btrfs die beiden aber auch sonst nicht: LVM bleibt für reine Block-Volumes (etwa für VMs oder Swap), für RAID-Level, die Btrfs nicht stabil abdeckt (RAID 5/6), und für andere Dateisysteme zuständig.

Dateisystem-Typen

  • Konventionelle Dateisysteme:
    Ext2, Ext3, Ext4, XFS, Btrfs, JFS, NTFS, etc.
  • Flash-Dateisysteme:
    ubifs, JFFS2, YAFFS, etc.
  • Spezielle Dateisysteme:
    procfs, sysfs, tmpfs, debugfs, etc.

Dateisystem-Limits

Bei den Maximalgrössen ist zwischen dem theoretischen Limit des Dateisystem-Designs und dem von Red Hat getesteten und unterstützten Limit zu unterscheiden. Die folgenden supported-Werte gelten laut Red Hat einheitlich für RHEL 8, 9 und 10; in Klammern steht, wo abweichend, der theoretische Wert.

Dateisystem

Max. Dateigrösse

Max. Dateisystemgrösse

Anmerkung

Ext4

16 TB (theoretisch 16 TiB)

50 TB (theoretisch 1 EiB)

Default bis RHEL 6

XFS

8 EB (theoretisch 8 EiB)

1 PB (theoretisch 8 EiB)

Default seit RHEL 7

Btrfs

16 EiB (theoretisch)

16 EiB (theoretisch)

nicht in RHEL/Rocky; keine supported-Werte

Wichtig: Bei Ext4 ist die maximale Datei (16 TB) deutlich kleiner als das maximale Dateisystem; eine einzelne Datei kann also nicht das ganze Dateisystem füllen. Die Anzahl Unterverzeichnisse ist bei XFS und Btrfs praktisch unbegrenzt, bei Ext4 standardmässig auf rund 65’000 begrenzt (durch das Feature dir_nlink aufgehoben, siehe FS: Ext4).

Snapshots

Ein Snapshot ist eine Momentaufnahme eines Dateisystems zu einem bestimmten Zeitpunkt, aus der sich der Stand später wiederherstellen lässt. Alle hier gezeigten Verfahren arbeiten Copy-on-Write: Der Snapshot teilt sich zunächst alle Blöcke mit dem Original und belegt erst dann eigenen Platz, wenn das Original nach dem Snapshot verändert wird. Welcher Weg in Frage kommt, hängt vom Dateisystem ab.

Dateisystem

Snapshot-Mechanismus

Verfügbar

Btrfs

nativ über Subvolumes

Fedora, SUSE (nicht RHEL/Rocky)

XFS

LVM-Snapshot oder Stratis

LVM seit RHEL 6, Stratis seit RHEL 8

Ext4

LVM-Snapshot

seit RHEL 6

Btrfs (nativ): legt Snapshots als Subvolume an und sichert sie mit btrfs send / btrfs receive, auch inkrementell. Details unter FS: Btrfs.

Ext4 und XFS (LVM): Das Dateisystem selbst kann keine Snapshots, die darunterliegende LVM-Schicht aber schon. Für einen konsistenten Snapshot wird das Dateisystem kurz eingefroren, damit keine halben Schreibvorgänge im Snapshot landen:

# quiesce the filesystem (generic; on XFS, xfs_freeze --freeze also works)
fsfreeze --freeze /data

# create a copy-on-write snapshot of the underlying logical volume
lvcreate --snapshot --size 5G --name lv_data_snap /dev/vg_data/lv_data

fsfreeze --unfreeze /data

Den Snapshot zum Wegsichern read-only mounten und mit tar oder rsync sichern. Zum Zurückrollen wird der Snapshot beim nächsten Aktivieren des Logical Volume in das Original gemerged:

# restore: merge the snapshot back into its origin
lvconvert --merge /dev/vg_data/lv_data_snap

Achtung

fsfreeze auf dem Wurzeldateisystem kann das laufende System blockieren, da alle Schreibzugriffe anhalten. Auf / nur mit Bedacht und kurz einsetzen. Ein LVM-Snapshot benötigt zudem freien Platz in der Volume Group.

XFS (Stratis): Stratis verwaltet einen thin-provisionierten Pool über XFS und bietet Snapshots ohne manuelles Freeze- und LVM-Hantieren. Der Snapshot ist selbst ein mountbares Dateisystem:

stratis filesystem snapshot pool1 fs1 fs1_snap

Details und Restore unter Stratis.

Quotas

Quotas begrenzen, wie viel Platz und wie viele Inodes ein Benutzer, eine Gruppe oder ein Projekt belegen darf. Das Modell unterscheidet sich je Dateisystem:

  • Ext4 und XFS kennen User-, Group- und Project-Quotas. Die Project-Quota begrenzt einen Verzeichnisbaum unabhängig vom Besitzer. Die Bedienung unterscheidet sich: ext4 nutzt die quota-Tools (edquota, setquota, repquota), XFS das eigene xfs_quota. Details unter FS: Ext4 und FS: XFS.

  • Btrfs hat kein User-/Group-/Project-Modell, sondern begrenzt über Quota Groups (qgroups) den Verbrauch je Subvolume. Details unter FS: Btrfs.

Jede Quota gilt immer nur für genau ein Dateisystem, nicht systemweit.

Grössenangaben

Die binären Einheiten (Basis 1024, Suffix i) und die dezimalen Einheiten (Basis 1000) werden in der Praxis oft vermischt. mkfs und die Dateisystem-Werkzeuge rechnen binär, viele Hersteller-Angaben dezimal.

  • 1 TiB (Tebibyte) = 1024 GiB

  • 1 TB (Terabyte) = 1000 GB

  • 1 PiB (Pebibyte) = 1024 TiB

  • 1 PB (Petabyte) = 1000 TB

  • 1 EiB (Exbibyte) = 1024 PiB

  • 1 EB (Exabyte) = 1000 PB