Aus dem Alltag eines Sysadmin: Konvertieren zu Btr-FS

In meinem Desktopsystem gibt es eine alte mit Ext 4 formatierte Festplatte, die mein Linux unter »/opt/data« einhängt. Hier kompiliere ich Software zum Ausprobieren. Alle paar Monate, wenn alles vollgemüllt ist, werfe ich den Inhalt von »/opt/data« in die Tonne. Da hier nie wichtige Daten lagern, wäre das spontane Ableben der Heesters-greisen Festplatte kaum schmerzlich. An ihr möchte ich heute die Dateisystemkonvertierung von Btr-FS ([1], [2]) testen.

Das 2007 vom Reiser-FS-erfahrenen Oracle-Mann Chris Mason als Prototyp vorgestellte Copy-on-Write-Filesystem errechnet selbstständig Prüfsummen, komprimiert Daten und fertigt Snapshots, arbeitet mit dynamische Inodes, speichert kleine Dateien hocheffizient und könnte so eines Tages Linux' offene Wunde in Sachen ZFS heilen.

Zurück zu meiner Geronten-Platte: Die hänge ich zunächst aus und gehe mit einem Filesystem-Check sicher, dass das Dateisystem keine Makel aufweist:

umount /dev/sdd1
fsck /dev/sdd1

Die eigentliche Konvertierung (siehe Abbildung 1) besorgt das Kommando:

btrfs-convert /dev/sdd1

An dieser Stelle hatte ich eine Kaffee-Zwangspause eingeplant, aber das Konvertierungstool meldet sich fast augenblicklich zurück. Offenbar fasst der Konverter die Datenblöcke überhaupt nicht an, sondern schreibt lediglich die Btr-FS-Metadaten neu. Außerdem legt er ein neues Subvolume an, das den Namen »ext2_saved« trägt.

Ein Subvolume ist, etwas vereinfacht, ein Verzeichnis innerhalb des neuen Dateisystems, das sich wie ein eigenständiges Volume benimmt. Jede Btr-FS-formatierte Partition besitzt das Subvolume »default« und darf (fast) beliebig viele weitere enthalten. Das »ext2_saved« -Subvolume, das der Konverter angelegt hat, enthält ein Abbild des früheren Ext-Volume, einen so genannten Snapshot. Er belegt anfangs kaum Platz auf der Festplatte, weil er nur die Daten speichert, die sich seit seinem Anlegen geändert haben – je mehr ich herumtue, umso größer wird der Snapshot.

Abbildung 1: Das Konvertieren eines Ext-2- in ein Btr-Dateisystem ist überraschenderweise zeitlich kein Akt.

Ein Rollback-Kommando

Sollte ich mit meinem Btr-FS nicht glücklich werden, könnte ich die Konvertierung mit dem Befehl

btrfs-convert -r /dev/sdd1

widerrufen. Der Befehl würde aus dem Snapshot mein altes Ext-Dateisystem wiederherstellen, lediglich die Änderungen seit dem Snapshot wären verloren. Jetzt will ich mein neues Btr-FS aber ausprobieren, also mounte ich es mit:

mount -o compress /dev/sdd1 /opt/data

Die Mountoption »-o compress« aktiviert die in Btr-FS eingebaute, aber normalerweise abgeschaltete Komprimierungsfunktion. Sie wird fortan bei jedem Schreibzugriff aktiv, bestehende Daten tastet Btr-FS vorerst nicht an. Eine nennenswerte CPU-Last verursacht der laufende Kompressor nicht. Clever: Die Engine erkennt bereits gepresste Dateien wie Jpeg oder MP3 und verschwendet keine Energie an sie.

Bis Btr-FS seine Versionsnummer auf 1.0 schaltet und meine altehrwürdigen Ext-Systeme ablöst, wird sicherlich noch einige Zeit ins Land gehen. Meine Experimente zeigen aber: Ich darf mich drauf freuen.

Der Autor

Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein in Kamp-Lintfort. Zu seinen Aufgaben gehören die Sicherheit und Verfügbarkeit der Firewalls und der DMZ. Im heißen Teil seiner Freizeit frönt er dem Kochen, im feuchten Teil der Süßwasseraquaristik und im östlichen lernt er Japanisch.