Mount Points und Dateisysteme: ext4, XFS, Btrfs im Vergleich

1. Was Mounten wirklich macht: Mount Points und das virtuelle Dateisystem

Ein Mount Point ist zunächst nichts weiter als ein gewöhnliches Verzeichnis, das durch den Systemaufruf mount() zum Einhängepunkt für ein Dateisystem wird. Der Linux-Kernel kennt intern kein Konzept von Laufwerksbuchstaben wie andere Betriebssysteme, sondern bildet alle verfügbaren Dateisysteme, Partitionen, Netzwerkfreigaben und sogar virtuelle Kernel-Schnittstellen wie /proc oder /sys in einem einzigen zusammenhängenden Verzeichnisbaum ab. Diese Abstraktionsschicht heißt Virtual File System (VFS) und sorgt dafür, dass Programme mit ext4, XFS, Btrfs, NFS oder tmpfs identisch interagieren können, ohne den zugrunde liegenden Treiber zu kennen. Solange ein Blockgerät nicht gemountet ist, bleibt sein Inhalt für den Rest des Systems unsichtbar, auch wenn die Partition physisch längst am Server angeschlossen ist.

Für den Betrieb eines Servers ist die Wahl der Mount Points keine Nebensächlichkeit. Wird beispielsweise /var/log als eigenes Dateisystem gemountet statt als Teil von /, kann ein außer Kontrolle geratenes Logfile niemals die Root-Partition und damit den gesamten Server zum Absturz bringen, weil ein volles Dateisystem seine Grenzen genau am Mount Point hat. Dieselbe Ueberlegung gilt für Uploads, Datenbank-Datenverzeichnisse oder Backup-Ziele: Wer sie sauber trennt, gewinnt unabhängige Kontrolle über Quotas, Snapshots, Mount-Optionen und Wiederherstellungsstrategien pro Dienst, statt ein einziges monolithisches Root-Dateisystem zu riskieren.

#!/usr/bin/env bash
# Inspect block devices and currently active mount points

lsblk -f
# NAME   FSTYPE FSVER LABEL UUID                                 MOUNTPOINT
# sda
# |-sda1 ext4   1.0         3f2b9a7e-9c1d-4e21-9a3a-1f6b2c8d4e10 /boot
# `-sda2 xfs          data  9a1c3e2f-8b7d-4c6a-b2e1-5d0f9a3c7b44 /

# Show the full mount tree with filesystem type and options
findmnt --real

# Manually attach a filesystem to an empty directory (mount point)
sudo mkdir -p /mnt/data
sudo mount -t xfs /dev/sdb1 /mnt/data

# Detach it again, e.g. before removing the device
sudo umount /mnt/data

2. /etc/fstab: Syntax und Aufbau im Detail

Die Datei /etc/fstab (file systems table) definiert, welche Dateisysteme beim Systemstart automatisch gemountet werden. Jede Zeile besteht aus sechs durch Leerzeichen oder Tabs getrennten Feldern: Gerät, Mount Point, Dateisystemtyp, Mount-Optionen, Dump-Flag und Pass-Nummer für fsck. Das Dump-Flag stammt aus einer Zeit vor modernen Backup-Werkzeugen und wird heute fast immer auf 0 gesetzt. Die Pass-Nummer steuert die Reihenfolge der Dateisystemprüfung beim Boot: 1 für das Root-Dateisystem, 2 für alle weiteren, 0 um die Prüfung komplett zu überspringen, etwa bei Netzwerkfreigaben oder journaling-basierten Dateisystemen wie XFS, die ihre eigene Konsistenzprüfung mitbringen.

# /etc/fstab: static filesystem information
# <device>                                  <mount point>  <fstype>  <options>                    <dump>  <pass>
UUID=3f2b9a7e-9c1d-4e21-9a3a-1f6b2c8d4e10    /boot          ext4      defaults                     0       2
UUID=9a1c3e2f-8b7d-4c6a-b2e1-5d0f9a3c7b44    /              xfs       defaults,noatime             0       1
UUID=7c4e1a20-55ab-4a9d-8e7f-2b0c9d5f6a31    /var/log       ext4      defaults,noatime,nofail      0       2
LABEL=backup-data                            /mnt/backup    ext4      defaults,nofail,x-systemd.device-timeout=10  0  2
tmpfs                                        /tmp           tmpfs     defaults,noatime,size=2G     0       0

Moderne Linux-Distributionen mit systemd übersetzen fstab beim Boot über den systemd-fstab-generator in reguläre Mount-Units, wodurch sich Einträge auch mit systemd-spezifischen Optionen wie x-systemd.device-timeout oder nofail absichern lassen. Ohne nofail hängt der komplette Bootvorgang, wenn ein in fstab eingetragenes Gerät fehlt, etwa ein externes Backup-Laufwerk oder ein NFS-Share, das beim Systemstart noch nicht erreichbar ist. Vor jedem Neustart sollte eine neue fstab-Zeile immer mit sudo mount -a getestet werden. Schlägt dieser Befehl fehl, wäre auch der nächste Boot fehlgeschlagen, und der Fehler lässt sich in Ruhe beheben, statt am Rettungssystem zu debuggen.

3. UUID, Label oder Gerätepfad: robuste Mount-Referenzen

Gerätepfade wie /dev/sda1 sind keine stabilen Bezeichner. Die Reihenfolge, in der der Kernel Blockgeräte beim Boot erkennt, hängt von Erkennungsreihenfolge, angeschlossenen USB-Geräten, NVMe-Controllern und sogar der Ladezeit einzelner Treibermodule ab. Nach einem Kernel-Update, dem Hinzufügen einer weiteren Festplatte oder einem Firmware-Wechsel kann aus /dev/sdb plötzlich /dev/sdc werden, mit fatalen Folgen, wenn fstab genau diesen Pfad referenziert und beim nächsten Boot die falsche Partition mountet oder der Systemstart ganz fehlschlägt.

Der robuste Weg ist die Referenzierung über die UUID, eine beim Formatieren erzeugte, eindeutige Kennung, die unabhängig von Erkennungsreihenfolge und Portbelegung bleibt. blkid listet UUID und Dateisystemtyp aller Blockgeräte auf, lsblk -f zeigt dieselben Informationen übersichtlicher als Baum. Für RAID-Controller oder Multipath-Storage mit mehreren Zugriffspfaden zum selben physischen Datenträger bieten sich zusätzlich die World-Wide-Name-basierten Pfade unter /dev/disk/by-id an, die selbst bei wechselnden Controllerpfaden konstant bleiben. Ein Label per e2label für ext4 oder xfs_admin -L für XFS ist eine dritte Option, die zusätzlich menschenlesbar bleibt, aber bei Duplikaten, etwa geklonten Datenträgern, mehrdeutig werden kann.

4. ext4 als sicherer Standard für Produktivserver

ext4 ist seit 2008 das Standarddateisystem der meisten Linux-Distributionen und aus gutem Grund die sichere Wahl für Root- und allgemeine Datenpartitionen auf einem Produktivserver. Als direkter Nachfolger von ext3 bringt es Extents statt klassischer Block-Zeiger, verzögerte Blockzuweisung (delayed allocation) für effizientere Schreibmuster und ein Journal mit Prüfsummen, das die Wahrscheinlichkeit von Journal-Korruption nach einem Absturz deutlich reduziert. Der entscheidende Vorteil liegt aber nicht in einzelnen Features, sondern in der schieren Reife: Kein anderes Linux-Dateisystem wurde über so viele Jahre unter derart vielfältigen Fehlerbedingungen getestet, und e2fsck gilt als das zuverlässigste Reparaturwerkzeug im gesamten Linux-Oekosystem.

Für die Praxis heißt das: Wo keine spezifische Anforderung wie extrem große Dateien oder Snapshot-Workflows vorliegt, ist ext4 der Standard, mit dem am wenigsten überraschende Betriebsprobleme auftreten. tune2fs erlaubt nachträgliche Anpassungen wie die reservierte Blockreserve für root, standardmäßig 5 Prozent, auf reinen Datenpartitionen oft sinnvoll auf 1 Prozent zu senken, oder das Deaktivieren des zeitbasierten erzwungenen fsck, das sonst nach einer festen Anzahl Tage einen unerwartet langen Boot mit vollständiger Dateisystemprüfung auslösen kann: tune2fs -c 0 -i 0 /dev/sda2 schaltet beide Automatismen ab, sodass Prüfungen nur noch gezielt manuell erfolgen.

5. XFS für große Dateien und parallele I/O-Last

XFS wurde ursprünglich von SGI für Workloads mit sehr großen Dateien und hohem parallelem Durchsatz entwickelt und bringt dieses Design bis heute mit: Das Dateisystem teilt sich intern in mehrere Allocation Groups auf, die unabhängig voneinander parallele Schreib- und Lesezugriffe verarbeiten können. Bei Workloads mit vielen gleichzeitigen Threads, etwa Datenbank-Datenverzeichnissen, Elasticsearch-Indizes, Video- oder Backup-Storage mit mehreren hundert Gigabyte großen Dateien, liefert XFS spürbar höheren Durchsatz als ext4. Red-Hat-Distributionen setzen XFS seit Jahren standardmäßig für Root-Dateisysteme ein, was seine Produktionsreife eindrucksvoll belegt.

Ein wichtiger praktischer Unterschied zu ext4: XFS lässt sich online vergrößern (xfs_growfs), aber niemals verkleinern. Wer eine XFS-Partition schrumpfen muss, kommt um Neuanlegen und Wiederherstellung aus einem Backup nicht herum, was bei der Planung von LVM-Layouts berücksichtigt werden sollte, gerade wenn Speicherplatz später zwischen Volumes verschoben werden soll. Für Verzeichnisse mit sehr vielen kleinen Dateien, etwa Millionen winziger Session-Dateien oder PHP-OpCache-Verzeichnisse, ist ext4 historisch gesehen tendenziell etwas günstiger in der Metadaten-Performance, auch wenn moderne XFS-Versionen diesen Abstand deutlich verkleinert haben.

# Create and inspect an XFS filesystem sized for large sequential files

sudo mkfs.xfs -f -L data /dev/sdb1
sudo xfs_info /mnt/data

# Grow the filesystem online after the underlying block device was extended
# (XFS can only grow, never shrink)
sudo xfs_growfs /mnt/data

# Defragment individual files without unmounting
sudo xfs_fsr /mnt/data/large-export.sql

6. Btrfs: Copy-on-Write, Snapshots und Subvolumes

Btrfs unterscheidet sich fundamental von ext4 und XFS durch sein Copy-on-Write-Prinzip (CoW): Statt einen belegten Block direkt zu überschreiben, schreibt Btrfs die geänderten Daten in neue, freie Blöcke und aktualisiert erst danach atomar die Metadaten-Zeiger. Diese Architektur macht Snapshots nahezu kostenlos, weil ein Snapshot lediglich einen weiteren Verweis auf den bestehenden Metadatenbaum anlegt, statt Daten physisch zu duplizieren. Subvolumes funktionieren dabei wie unabhängig mountbare, eigenständig snapshotbare Verzeichnisbäume innerhalb eines einzigen Dateisystems, was für Deployment-Workflows enorm praktisch ist: Vor einem riskanten Update lässt sich in Sekundenbruchteilen ein Rollback-Punkt anlegen, ohne den Dienst zu stoppen.

Die Kehrseite von CoW zeigt sich bei schreiblastigen Datenbankdateien wie InnoDB-Tablespaces: Ständige kleine Random-Writes erzeugen auf Btrfs deutlich mehr Fragmentierung als auf ext4 oder XFS, was die Performance über Zeit messbar verschlechtern kann. Die Lösung ist chattr +C auf dem betroffenen Verzeichnis, wodurch Copy-on-Write für neue Dateien darin deaktiviert wird, allerdings auf Kosten der Prüfsummen-Integrität für genau diese Dateien. Von Btrfs im RAID5- oder RAID6-Modus wird für produktive Daten weiterhin abgeraten, da dort bekannte Schreiblochprobleme (write hole) bestehen. Regelmäßige btrfs scrub-Läufe zur Prüfsummen-Validierung und btrfs balance zur Verteilung der Datenblöcke gehören zur Pflichtwartung.

# Create a subvolume and take an atomic, near-instant snapshot

sudo btrfs subvolume create /mnt/data/webroot
sudo btrfs subvolume snapshot -r /mnt/data/webroot /mnt/data/webroot-2026-07-12

# Disable copy-on-write for a database directory to avoid write amplification
sudo chattr +C /mnt/data/mysql

# Regular maintenance: verify checksums and rebalance chunks
sudo btrfs scrub start /mnt/data
sudo btrfs balance start -dusage=50 /mnt/data

7. Performance-Mount-Optionen: noatime, nodiratime, discard

Standardmäßig aktualisiert Linux bei relatime, dem heutigen Distributions-Standard, den letzten Zugriffszeitstempel (atime) einer Datei bei jedem Lesezugriff, sofern der bisherige Zeitstempel älter als der letzte Aenderungszeitpunkt oder älter als ein Tag ist. Das klingt harmlos, bedeutet aber auf einem Webserver mit Millionen von Lesezugriffen auf Bilder, CSS- und JS-Assets Millionen zusätzlicher Metadaten-Schreibvorgänge. Die Mount-Option noatime deaktiviert diese Aktualisierung vollständig und schließt nodiratime implizit mit ein. Der Effekt ist auf I/O-intensiven Servern spürbar: weniger Schreiblast, geringere SSD-Abnutzung, niedrigere Latenz bei Lesezugriffen.

Bevor noatime global gesetzt wird, lohnt eine kurze Prüfung, ob irgendein Dienst tatsächlich von atime abhängt. Klassische Kandidaten sind Mailserver, die unbesehene Nachrichten anhand von atime erkennen, etwa mutt oder manche IMAP-Server, oder alte Aufräum-Skripte, die Dateien nach letztem Zugriff statt nach letzter Aenderung löschen. Auf SSDs ist zusätzlich die discard-Option relevant, die dem Controller nicht mehr benötigte Blöcke per TRIM-Kommando meldet. Statt discard dauerhaft im Mount zu setzen, was bei jedem Löschvorgang eine synchrone TRIM-Operation auslöst und die Latenz erhöhen kann, ist der periodische fstrim.timer über systemd, einmal wöchentlich, meist die bessere, planbarere Alternative.

{
  "filesystems": [
    {
      "target": "/",
      "source": "/dev/sda2",
      "fstype": "xfs",
      "options": "rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota"
    },
    {
      "target": "/var/log",
      "source": "/dev/sda3",
      "fstype": "ext4",
      "options": "rw,noatime,nofail,errors=remount-ro"
    }
  ]
}

8. Sicherheits-Mount-Optionen: barrier, nobarrier und Journaling-Modi

Write Barriers stellen sicher, dass ein Journal-Commit tatsächlich dauerhaft auf dem physischen Datenträger angekommen ist, bevor das Dateisystem ihn als abgeschlossen betrachtet, indem sie den flüchtigen Schreibcache der Festplatte oder SSD gezielt leeren (Cache Flush). Ohne diese Absicherung kann bei einem Stromausfall die Journal-Reihenfolge durcheinandergeraten, und das Dateisystem findet nach dem Neustart einen inkonsistenten Zustand vor, der im schlimmsten Fall zu Datenverlust führt. Die Mount-Option nobarrier deaktiviert diesen Mechanismus und verspricht dafür etwas höheren Schreibdurchsatz, weil der Cache Flush entfällt.

nobarrier ist nur dann sicher, wenn die zugrunde liegende Hardware selbst garantiert, dass Daten den Schreibcache auch bei Stromausfall überleben, etwa bei einem Hardware-RAID-Controller mit batteriegepuffertem Cache (BBU) oder Enterprise-SSDs mit Power-Loss-Protection-Kondensatoren. Auf gewöhnlichen Consumer-SSDs, virtuellen Maschinen ohne durchgereichte Power-Loss-Garantie oder klassischen Festplatten ohne BBU-Controller riskiert nobarrier stille Dateisystem-Korruption nach einem harten Absturz. Ergänzend steuert bei ext4 die Option data=ordered, der Standard, einen ausgewogenen Kompromiss zwischen Sicherheit und Geschwindigkeit, data=journal protokolliert zusätzlich Nutzdaten und ist am sichersten, aber spürbar langsamer, während data=writeback die schnellste, aber riskanteste Variante ist, weil nach einem Absturz alte Daten in neu allozierten Blöcken auftauchen können.

9. Dateisysteme und Mount-Strategien im direkten Vergleich

Die Wahl zwischen ext4, XFS und Btrfs ist keine grundsätzliche Entscheidung, sondern eine Frage des konkreten Workloads: ext4 bleibt der risikoärmste Standard für Root-Dateisysteme und allgemeine Serveraufgaben, XFS zahlt sich bei großen Dateien und parallelem I/O aus, Btrfs lohnt sich dort, wo Snapshot-basierte Rollback-Strategien einen echten operativen Mehrwert bringen. Genauso wichtig wie die Dateisystemwahl ist aber, welche Mount-Optionen tatsächlich gesetzt werden, denn eine falsch gewählte Option kann die Vorteile jedes Dateisystems zunichtemachen oder im schlimmsten Fall Daten gefährden.

Die Tabelle zeigt, dass Sicherheit und Performance selten im Widerspruch stehen, wenn die richtige Option zum richtigen Workload passt. UUID-Referenzen statt Gerätepfade, nofail für optionale Datenträger und ein bewusster Umgang mit nobarrier verhindern die häufigsten produktionsrelevanten Ausfälle, während noatime und die passende Dateisystemwahl die Performance heben, ohne die Datensicherheit zu kompromittieren.

10. Zusammenfassung

Mount Points sind der Mechanismus, über den Linux Blockgeräte, Netzwerkfreigaben und virtuelle Kernel-Schnittstellen zu einem einzigen Verzeichnisbaum verbindet, und /etc/fstab definiert, welche dieser Verbindungen beim Systemstart automatisch hergestellt werden. UUID-Referenzen statt Gerätepfade und die Option nofail für nicht kritische Datenträger verhindern die häufigsten Boot-Probleme. Bei der Dateisystemwahl bleibt ext4 der sichere Standard für die meisten Server, XFS gewinnt bei großen Dateien und paralleler I/O-Last, und Btrfs lohnt sich dort, wo Snapshot-Workflows einen echten operativen Vorteil bringen.

Mount-Optionen entscheiden am Ende genauso stark über Performance und Sicherheit wie die Dateisystemwahl selbst. noatime reduziert unnötige Schreiblast auf I/O-intensiven Servern spürbar, während nobarrier nur mit Hardware verwendet werden darf, die Schreibcache-Persistenz bei Stromausfall garantiert. Wer diese Entscheidungen bewusst und workload-spezifisch trifft, statt Standardwerte unreflektiert zu übernehmen, baut Server-Storage, der sowohl schnell als auch im Ernstfall wiederherstellbar ist.

11. FAQ: Mount Points und Dateisysteme