Btrfs/Grundlagen

Grundlegende Konzepte

Dateisystem und Geräte

Bei btrfs gibt es keine 1:1-Beziehung zwischen physikalischem Gerät (d.h. einer Festplattenpartition) und Dateisystem

• Da btrfs ein integriertes Volume Management ähnlich Vorlage:Deb mit sich bringt, muss man sich vorstellen, dass ein btrfs-Dateisystem immer auf einem „Pool“ von physikalischen Geräten aufsetzt
• Bei der Nutzung des Dateisystems ist es für den Anwender weitestgehend irrelevant, wie das Dateisystem die einzelnen Geräte anspricht

Copy-on-Write

Copy-on-Write bedeutet, dass beim Kopieren von Daten diese erst in dem Moment „echt“ kopiert werden, wenn diese verändert werden

• Vorher „zeigen“ sowohl Original als auch Kopie auf die gleichen Speicherbereiche

Dieses Verfahren wird für Snapshots genutzt: ein Snapshot ist „sofort“ angelegt, da dafür keine wesentlichen Datenmengen kopiert werden müssen, und belegt keinen zusätzlichen Speicherplatz. Änderungen am Original werden in neue Speicherbereiche geschrieben

Copy-on-Write lässt sich über die Mountoption nodatacow global abschalten

• Für einzelne Dateien kann es über chattr gesteuert werden
• Die Deaktivierung kann für bestimmte Dateien sinnvoll sein, bspw
• für Images von virtuellen Maschinen oder Datenbankdateien

Chunks

Die Daten werden in Chunks (auch Block Groups) genannt abgelegt

• Ein Chunk ist ein Speicherbereich fester Größe
• Es gibt drei unterschiedliche Chunk Types:
• Data: diese Chunks speichern ausschließlich Dateiinhalte
• Ein Data Chunk ist in der Regel 1 GiB groß
• Metadata: diese Chunks speichern dateisysteminterne Metadaten in B-Bäumen sowie kleine Dateien, wenn sie in den Chunk hineinpassen
• Ein Metadata Chunk ist abhängig von der Dateisystemgröße 256 MiB oder 1 GiB groß
• System: diese Chunks speichern Informationen über die Geräte, auf denen das Dateisystem liegt
• System Chunks sind ein paar MiB groß

Profile

Für die drei Chunk Types können Chunk Profiles ausgewählt werden

• Die Profile entscheiden, wie die Chunks auf die physikalischen Geräte verteilt werden
• In der Manpage von mkfs.btrfs findet sich eine Übersicht:

┌────────┬────────────────────────────────────┬────────────┐
│ │ │ │
│Profile │ Redundancy │ Min/max │
│ ├──────────────┬────────┬────────────┤ devices │
│ │ │ │ │ │
│ │ Copies │ Parity │ Striping │ │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│single │ 1 │ │ │ 1/any │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│ DUP │ 2 / 1 device │ │ │ 1/any (see │
│ │ │ │ │ note 1) │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│ RAID0 │ │ │ 1 to N │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│ RAID1 │ 2 │ │ │ 2/any │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│RAID10 │ 2 │ │ 1 to N │ 4/any │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│ RAID5 │ 1 │ 1 │ 2 to N - 1 │ 2/any (see │
│ │ │ │ │ note 2) │
├────────┼──────────────┼────────┼────────────┼────────────┤
│ │ │ │ │ │
│ RAID6 │ 1 │ 2 │ 3 to N - 2 │ 3/any (see │
│ │ │ │ │ note 3) │
└────────┴──────────────┴────────┴────────────┴────────────┘

Bei der Erzeugung eines btrfs-Dateisystems auf einer rotierenden Festplatte wird mkfs.btrfs für Metadata- und System-Chunks das Profil DUP wählen, auf einer SSD dagegen Single

• Durch die redundante Speicherung wird die Ausfallsicherheit erhöht
• Da viele SSD-Controller intern Deduplizierung betreiben, lässt sich dort die Sicherheit so nicht erhöhen, weshalb mkfs.btrfs dann Single wählt

Neben den in der Tabelle gezeigten Profilen werden nach und nach weitere Profile für besondere Einsatzzwecke hinzugefügt, bspw

• für Metadaten für Daten-RAID56
• Für eine aktuelle Übersicht schaut man am Besten in der Manpage nach

Subvolumes

Ein Subvolume ist eine zusätzliche interne Dateisystemwurzel, die separat eingehängt werden kann

• Aus Anwendungssicht erscheinen Subvolumes wie Verzeichnisse, sie lassen sich jedoch nicht über rmdir löschen
• Auch ein rm -rf auf ein Verzeichnis schlägt fehl, wenn darin Subvolumes enthalten sind

Subvolumes sind die Grundlage für Snapshots und Quotas

Befehle

Für den Umgang mit btrfs-Dateisystemen müssen die btrfs-progs installiert werden

Das grundlegende Userspace-Tool heißt btrfs

Wichtige Befehle

btrfs balance	Ausbalancieren eines Dateisystem, d. h. die Neuanordnung der Chunks, in denen die Daten abgelegt sind
btrfs check	diverse Offline-Überprüfungen eines btrfs-Dateisystems
btrfs device	Verwaltung der einem btrfs-Dateisystem zugeordneten Geräte
btrfs filesystem	Verwaltung eines btrfs-Dateisystems an sich
btrfs qgroups	Verwalten von Quota Groups
btrfs quota	Verwalten von Quotas
btrfs replace	Austauschen von Geräten bei RAID
btrfs rescue	Reparieren beschädigter Dateisysteme
btrfs scrub	Online-Überprüfungen eines btrfs-Dateisystems
btrfs subvolume	Verwaltung von btrfs-Subvolumes und Snapshots

Für jeden Befehl gibt eine Manpage | Die für balance ruft man bspw. über

man btrfs-balance

auf

btrfs-Dateisysteme erzeugen

Ein btrfs-Dateisystem wird mit mkfs.btrfs angelegt

root@demo:~# mkfs -t btrfs /dev/sdb1
btrfs-progs v4.20.1
See http://btrfs.wiki.kernel.org for more information

Label: (null)
UUID: 13e1b03d-1610-436f-8589-925897f2a1ca
Node size: 16384
Sector size: 4096
Filesystem size: 8.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 409.50MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Number of devices: 1
Devices:
ID SIZE PATH
1 8.00GiB /dev/sdb1

Kompression

btrfs bietet eine transparente Datenkompression, die sich mit der mount-Option compress aktivieren lässt

• Neu geschriebene oder veränderte Daten werden dann automatisch komprimiert
• Das Dateisystem erkennt anhand eines Algorithmus’, welche Daten sich komprimieren lassen
• Dadurch können Daten auch unkomprimiert gespeichert werden

Verschlüsselung

Eine integrierte Verschlüsselung ist nicht vorhanden

• Will man btrfs verschlüsseln, so kann man Vorlage:Deb verwenden
• Da btrfs auf mehreren Geräten aufsetzen kann, muss man darauf achten, jedes Gerät zu verschlüsseln
• Weitere Informationen gibt im btrfs-Wiki. (Bitte beachten: das Wiki spiegelt immer den aktuellen Entwicklungsstand von btrfs wieder, der nicht mit dem in Debian übereinstimmen wird.)

Freien Speicherplatz anzeigen

btrfs speichert die Daten intern in sog

• Chunks, die Datenbereiche bestimmter Größe darstellen
• Innerhalb eines Chunks können Daten unterschiedlicher Dateien abgelegt werden
• Für das Vorhandensein freien Speicherplatzes auf einem btrfs-Dateisystem ist das Vorhandensein freier Chunks entscheidend
• Anders ausgedrückt: bei btrfs muss man zwischen freiem Platz auf dem Dateisystem und freiem Platz auf den Geräten unterscheiden

Da btrfs mit Copy-on-Write arbeitet und die Daten in Chunks allokiert, sind die Ausgaben von df und du mitunter irreführend

• Bei Vorhandensein von Snapshots kann du u.U
• mehr belegten Platz ausweisen, als das Dateisystem groß ist

root@proliant:~# df -h /
Dateisystem Größe Benutzt Verf

• Verw% Eingehängt auf

/dev/sda1 105G 35G 69G 34% /
root@proliant:~# btrfs filesystem show /
Label: none uuid: 2a485f0a-0fcc-4198-a92e-e0a9f854ac46
Total devices 1 FS bytes used 33.98GiB
devid 1 size 104.31GiB used 61.03GiB path /dev/sda1

Wie interpretiert man diese Ausgabe?

• Total devices 1: das Dateisystem liegt ist einem Gerät zugeordnet
• FS bytes used 33.98GiB: auf dem Dateisystem sind 33,98 GiB belegt
• devid 1: es folgen Angaben zum ersten zugeordneten Gerät
  • size 104.31GiB: dieses Gerät ist 104,31 GiB groß
  • used 61.03GiB: es sind Chunks im Volumen von 61,03 GiB in Verwendung
  • path /dev/sda1: das Gerät ist /dev/sda1

Die entscheidende Angabe ist die unterhalb der Devices: sie gibt an, in welchem Umfang Chunks belegt sind

• Wenn keine freien Chunks mehr vorhanden sind, ist das Dateisystem voll
• Bei der Angabe der belegten Chunks werden diese immer voll gezählt unabhängig davon, in welchem Umfang sie belegt sind

Im Beispiel oben sind also nicht die von df ausgegebenen 69 GB frei

• Das Dateisystem wird weitaus früher melden, dass kein Speicherplatz mehr vorhanden ist

Wird innerhalb eines Chunks Speicherplatz durch Löschen einer Datei frei, so wird der Chunk immer noch als voll belegt angezeigt

• Durch Neubalancieren des Dateisystems können Daten zwischen Chunks verschoben und so freier Speicherplatz gewonnen werden
• Chunks, die keine Daten mehr enthalten, werden freigegeben

Wie sich die belegten Daten über unterschiedliche Chunks verteilen, lässt sich über

root@proliant:~# btrfs filesystem df /
Data, single: total=59.00GiB, used=33.33GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=2.00GiB, used=668.80MiB
GlobalReserve, single: total=81.98MiB, used=0.00B

detaillierter anzeigen

• Die Angabe „single“ zeigt an, dass es sich hier um Chunks handelt, die nur auf einem Gerät existieren

Aber wieviel Platz ist belegt? Die Ausgabe von du ist genau wie die von df irreführend:

root@proliant:~# du -h --max-depth=0 /var/lib/lxc/
83G /var/lib/lxc/

du meldet, dass unterhalb eines Verzeichnisses 83 GB belegt sind

• Dies rührt daher, dass btrfs mit Copy-on-Write arbeitet, mehrere identische Dateien also nur einmal Speicherplatz belegen, du diesen aber mehrfach zählt
• Im Beispiel oben existieren unter /var/lib/lxc mehrere Snapshots, die aber nur in soweit Speicherplatz belegen, wie sich das per Snapshot gesicherte Subvolume verändert hat
• Auch das kann man sich ausgeben lassen:

root@proliant:~# btrfs filesystem du -s /var/lib/lxc
Total Exclusive Set shared Filename
69.35GiB 2.30GiB 8.54GiB /var/lib/lxc

Tatsächlich sind nur knapp 11 GiB belegt, von denen 8,54 GiB von mehreren Snapshots und den Originalen gemeinsam verwendet werden

• Nur 2,30 GiB entfallen auf sich unterscheidende Daten

Balancieren

Unter Balancieren oder Balancing wird die Neuanordnung der Daten in den Chunks verstanden

Dies ist im Regelfall in zwei Fällen erforderlich

• Das Chunk-Profil soll gewechselt werden
• Beispiele dazu finden sich weiter unten unter Multidisk zu finden
• Der Speicherplatz geht zur Neige, weil nur noch wenige freie Chunks vorhanden sind
• Per Balancieren kann man btrfs dazu bewegen, Daten aus wenig belegten Chunks in andere Chunks zu verlagern und anschließend nicht mehr verwendete Chunks freizugeben

Das Ergebnis sieht man hier in einer (gekürzten) Ausgabe von btrfs-balance, eines Tools von btrfsmaintenance:

/etc/cron.monthly/btrfs-balance:
Before balance of /
Data, single: total=60.00GiB, used=29.93GiB
System, single: total=64.00MiB, used=16.00KiB
Metadata, single: total=2.00GiB, used=582.12MiB
GlobalReserve, single: total=74.83MiB, used=0.00B
Dateisystem Größe Benutzt Verf

• Verw% Eingehängt auf

/dev/sda1 112G 33G 78G 30% /
Done, had to relocate 0 out of 64 chunks
Dumping filters: flags 0x1, state 0x0, force is off
DATA (flags 0x2): balancing, usage=1
Done, had to relocate 0 out of 64 chunks
…
Dumping filters: flags 0x6, state 0x0, force is off
METADATA (flags 0x2): balancing, usage=30
SYSTEM (flags 0x2): balancing, usage=30
Done, had to relocate 2 out of 39 chunks
After balance of /
Data, single: total=36.00GiB, used=29.92GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.00GiB, used=577.44MiB
GlobalReserve, single: total=70.14MiB, used=0.00B

Vorher waren Data Chunks im Umfang von 60 GiB vorhanden, die nur knapp 30 GiB Daten enthielten

• Danach waren Data Chunks im Umfang von 36 GiB vorhanden
• De facto sind 24 GiB Speicherplatz freigeworden. (Das darunterliegende Gerät ist übrigens 104,31 GiB groß.)

Das Balancieren zum Neuordnen von Chunks wird über den Filter usage gesteuert

• Möchte man bspw
• alle Data Chunks, die zu weniger als 40% belegt sind, umgliedern, so geschieht dies über btrfs balance -dusage=40 /
• Den Prozess muss man möglicherweise mehrfach wiederholen und dabei steigende Prozentwerte verwenden
• Das oben gezeigte btrfsmaintenance führt wiederholtes Balancieren mit steigenden Prozentwerten bis 30% durch

Scrubbing

Beim Scrubbing werden alle Daten mit den gespeicherten Prüfsummen verglichen

• Bei redundant gespeicherten Chunks (Profile DUP, RAID1/5/6) werden Fehler automatisch korrigiert
• Es wird über btrfs scrub ausgelöst

Das Ergebnis sieht man hier in einer Ausgabe von btrfs-scrub, eines Tools von btrfsmaintenance:

/etc/cron.monthly/btrfs-scrub:
Running scrub on /
scrub device /dev/sda1 (id 1) done
scrub started at Fri Dec 1 07:06:06 2017 and finished after 00:01:26
total bytes scrubbed: 30.49GiB with 0 errors

Scrubbing belastet die Festplatte und den Prozessor enorm

• Der Vorgang kann bei großen Dateisystemen mehrere Stunden dauern

Debian auf btrfs installieren

Der Debian-Installer installiert Debian auf btrfs, wenn dieses während der Installation explizit ausgewählt wird

• Die btrfs-progs werden dann automatisch installiert