Dies ist eine alte Version des Dokuments!

Inhaltsverzeichnis

BTRFS

BTRFS

BTRFS ist ein modernes Copy-on-Write-Dateisystem (COW) für Linux, das auf die Implementierung erweiterter Funktionen abzielt und gleichzeitig den Schwerpunkt auf Fehlertoleranz, Reparatur und einfache Verwaltung legt. Seine Hauptfunktionen und Vorteile sind:

Snapshots, die keine vollständige Kopie der Dateien erstellen
Integriertes Volume-Management, Unterstützung für softwarebasiertes RAID 0, RAID 1, RAID 10 und andere
Selbstheilung – Prüfsummen für Daten und Metadaten, automatische Erkennung stiller Datenbeschädigungen

Dateisystem Erstellung

Ein BTRFS Dateisystem wird mit mkfs.btrfs erstellt. Die häufigsten Optionen, die bei der Erstellung des Dateisystems mit angeben werden sind:

-L Um dem Dateisystem ein Label zu geben
--csum Um den gewünschten Checksummen Algorithmus auszuwählen (Standard ist crc32c). Dies lässt sich nachträglich nicht mehr ändern!
-O Um nicht benötigte Funktionen wie z.b. die raid56 oder quota an/abzuschalten. Für eine vollständige Liste siehe auch -O list-all

Beispielbefehl

Dieser Befehl gibt dem Dateisystem einen Namen, verwendet den xxhash Algorithmus für Checksummen und deaktiviert die Funktionen raid56 und quota:

# mkfs.btrfs -L "Label-Name" --csum xxhash -O ^raid56,^quota

Subvolumen

Ein BTRFS-Subvolumen ist ein Teil eines Dateisystems mit einer eigenen, unabhängigen Datei-/Verzeichnishierarchie und einem Inode-Nummern-Namespace. Subvolumen können Dateibereiche gemeinsam nutzen.

Hinweis: Subvolumen können verwendet werden, um bei der Erstellung eines Snapshots dieses Subvolumen auszulassen. Da immer nur das angebe, Subvolumen von einem Snapshot betroffen ist und andere Subvolumen nicht mit gesichert werden.

Für weitere Informationen siehe:

Btrfs Subvolumen Dokumentation
Suletuxe Forum Eintrag (Einfachere sinnbildliche Beschreibung eines Subvolumen)

Subvolumen Erstellung

Dieser Befehl geht davon aus, dass man sich im Root Verzeichnis seines Btrfs Dateisystems (Subvolume ID 5) befindet. Und legt gleich mehrere Subvolumen auf einmal an. @ für das Betriebssystem Wurzel Verzeichnis, @home für das /home Verzeichnis @cache für /var/cache und @.snapshots für spätere Snapshots Ablage unter /.snapshots.

# btrfs subvolume create @ @home @cache @.snapshots

Optionales @log Subvolumen

Für spätere forensische Untersuchungen der Logs, könnte man das Verzeichnis /var/log in einem eigenen Subvolumen @log auslagern, damit bei einem Rollback des @ Subvolumes die Logs erhalten bleiben.

Die Auslagerung des /var/log Verzeichnisses in ein separates beschreibbaren Subvolumen ist eine Voraussetzung, falls man vorhat in einem Readonly Snapshots seines @ Subvolumen zu booten.

Subvolumen Mounten

Es folgt ein Beispiel Mount Befehl, um ein angelegtes Subvolumen direkt zu mounten. Die wichtige Mount Option ist hierbei subvol= womit das gewünschte Subvolumen angeben wird. Andere beliebte Mount Optionen sind noatime,compress=zstd,discard

# mount -t btrfs -o noatime,subvol=@ /dev/sdX /mnt/

Beispiel fstab Eintrag

Es folgt ein umfangreicher Beispiel fstab Eintrag:

UUID=c6757eef-ba72-4038-847f-a2ef19cf9c52 / btrfs rw,noatime,compress=zstd:3,ssd,space_cache=v2,subvol=/@ 0 0

Snapshots

Ein Snapshot ist ebenfalls ein Subvolumen, jedoch mit einem vorgegebenen Anfangsinhalt des ursprünglichen Subvolumen. Ein Subvolumen hat immer die Inode-Nummer 256. Somit kann ein Snapshot wie eine schnelle Art von Referenzierung mit dem Inhalt eines anderen Subvolumen betrachtet werden, das sich nicht mit ändert.

Hinweis: Subvolumen können verwendet werden, um bei der Erstellung eines Snapshots dieses Verzeichnis (Subvolumen) auszulassen. Da immer nur das Angebe Subvolumen von einem Snapshot betroffen ist und andere Subvolumen nicht mit gesichert werden.

Snapshot Anlegen

Ein Snapshot wird so angelegt:

-r legt ein Read-only Snapshot an.

btrfs subvolume snapshot [-r] <subvolume> <Speicherort des Snapshots>

Siehe auch

Btrfs Dokumentation Subvolumes

Snapshot Automation

Das Anlegen von eines Snapshots lässt sich mithilfe verschiedener Tools automatisieren. Eins davon ist yabsnap^AUR. Für eine Erläuterung siehe dazu:

chroot Hinweis

Es ist meist nicht gewollt, aus dem Wurzelverzeichnis (ID 5) in ein Subvolume zu chrooten. Angenommen die Dateisystem Wurzel ist unter /mnt/btrfs gemountet und hier liegt ein Subvolume @ (/mnt/btrfs/@):

Dann möchte man nicht:

chroot /mnt/btrfs/@

sondern vielmehr in das gemountet Subvolumen chrooten:

mount --mkdir -t btrfs -o noatime,subvol=@ /dev/sdX /mnt/btrfs-@/
chroot /mnt/btrfs-@/

Swapdatei

Wenn eine Swapdatei verwendet werden soll, gibt es ein paar Dinge zu beachten:

Eine Swapdatei kann nur mit dem Single Data Profil verwendet werden. Dies schließt eine Nutzung der Btrfs RAID Profile aus!
Das Subvolumen, worin sich eine Swapdatei befindet, kann kein Snapshot für angelegt werden. Daher ist es ratsam die Swapdatei alleine für sich in ein eigenes Subvolumen z.B.@swap anzulegen. Und diese z.b. unter /swap/ zu mounten.
Für die Swapdatei muss COW deaktiviert sein. COW lässt sich anfänglich nur für leere Dateien abschalten. um den Vorgang zu vereinfachen haben die btrfs tools eine Hilfefunktion dafür, die diese schritte mit erledigt, siehe Swapdatei anlegen.
Soll die Swapdatei z.B. für den Ruhezustand verwendet werden, so lässt sich das Offset der Swapdatei nicht mit filefrag -v bestimmen. Da Btrfs eine Abstraktionsschicht zum Mappen der Dateien verwendet. um das Offset zu bestimmen, gibt es auch eine Hilfefunktion in den btrfs tools siehe Offset der Swapdatei bestimmen

Swapdatei anlegen

# btrfs filesystem mkswapfile -U clear -s 2G <Datei>

-U gibt eine UUID für die Swapdatei an.
-s Gibt die größe der Swapdatei an (Standard ist 2 GiB)

Offset der Swapdatei bestimmen

btrfs inspect-internal map-swapfile -r <swapdatei>

siehe auch

btrfs Dokumentation - Swapfile

NO_COW

Verzeichnis und/oder Dateien, deren Inhalt sich schnell und häufig ändert, wirkt sich COW nachteilig auf die Geschwindigkeit des Dateisystems aus.

Wichtig: für NO_COW Dateien werden keine Checksummen gebildet. Dadurch kann keine stille Datenbeschädigung festgestellt werden. Und damit auch die Selbstheilung der Dateien deaktiviert, falls diese z.b. durch ein RAID1 Profil redundant vorgehalten werden. Da Btrfs schlicht und einfach nicht mehr feststellen kann, welche Version der Datei die noch intakte Variante ist.

Beispiele hierfür sind:

Virtuelle Maschinen Datei Images
Datenbanken
Logdateien
Verzeichnisse, in dem Software compiliert wird und viele kleine temporäre Dateien entstehen.

Für solche Anwendungsfälle lässt sich COW deaktivieren. Dies kann mithilfe des C ACL Flags erreicht werden. Wird das Flag auf ein Verzeichnis angewandt, so bekommen alle neu angelegten Dateien automatisch das C (nocow) zugewiesen.

Soll hingegen das C Flag auf eine Datei direkt angewandt werden, muss sichergestellt sein, dass diese Datei leer ist.

Ergänzender weise sei noch die nodatacow mount Option erwähnt. Diese lässt sich aber meist nicht verwenden, da momentan Subvolumen noch nicht mit unterschiedlichen Mount Optionen gemountet werden können. Und somit dies nicht größtenteils nicht sinnvoll genutzt werden kann.

Beispiele

Setzen des C Flags

chattr +C <Verzeichnis/Datei>

Nachträgliches setzten des C Flags auf eine Datei mit Inhalt

$ mv /path/to/dir /path/to/dir_old
$ mkdir /path/to/dir
$ chattr +C /path/to/dir
$ cp -a --reflink=never /path/to/dir_old/. /path/to/dir
$ rm -rf /path/to/dir_old

Auswirkungen auf Snapshots

Für einen Snapshot ist COW erfoderlich. Aus diesem Grund wird beim anlegen eines Snapshots bei der ersten Schreibopertation auf eine NO_COW Datei. Eine COW Kopie für den Snapshot erstellt. Die nachfolgenden Schreibforgänge erfolgen dann wieder mit NO_COW. Da das anlegen häufiger Snapshots von solchen Dateien wieder die Geschwindigkeit negativ beinflusst. Wird empfholen solche Dateien in einen eigenes Subvolumen unterzubringen das von dem Snapshot ausgeschlossen wird.

siehe auch

Siehe auch