Das Dateisystem Btrfs
Seite 2: Praxis
Praxis
Die gerade erschienene erste Vorabversion des kommenden Kernels 2.6.31 enthält die neue Btrfs-Version 0.19, in dem sich die Datenstrukturen auf der Festplatte gegenüber der Vorversion geändert haben. 2.6.31-RC1 gibt es nur als Patch für 2.6.30. Also benötigt man erst einmal dessen Quellen (gibts für Ubuntu 9.04 als fertiges Paket), dann wird der Patch drüber gebügelt. Wie ging das noch mal? Ach ja, patch -p1. Wann habe ich eigentlich zum letzten Mal selbst einen Linux-Kernel übersetzt? Natürlich gibt es ein paar Rejects (vielleicht wäre der 2.6.30 von kernel.org doch die bessere Wahl gewesen?), aber das lässt sich mit ein bisschen gesundem Menschenverstand in den Quelltexten reparieren.
Erst mal mit make oldconfig die Konfiguration des 2.6.30 von Ubuntu einspielen, als vernünftige Grundkonfiguration – man will bei der Kernelkonfiguration ja nicht jedes Treiber-Untermenü abklappern müssen. Diverse neue Einstellungen sind hinzugekommen, einiges davon klingt spannend, aber jetzt geht es nur um das Btrfs – die anderen Neuerungen sind Thema des Kernel-Logs. Noch ein schnelles make menuconfig, unter "File Systems" Btrfs als Modul aktivieren, fertig.
Wie lautet noch mal der Parameter, um make parallel laufen zu lassen? Ach ja, -j, richtig. Die Fehler beim Kompilieren beschränken sich auf die Ubuntu-eigenen Treiber im Kernel – der Vanilla-Kernel wäre definitiv die bessere Wahl gewesen. Aber der Ubuntu-Kram ist in .config schnell auskommentiert, und dann läuft make durch. Noch eine neue Init-RAM-Disk für 2.6.31-rc1 bauen, /boot/grub/menu.lst anpassen, Reboot – klappt. Kernel kompilieren ist halt doch wie Fahrrad fahren: Wer es mal gelernt hat, vergisst es nicht mehr.
Da das in den Ubuntu-Repositories verfügbare Paket btrfs-tools noch auf dem Versionsstand 0.18 ist, müssen auch die Userland-Tools heruntergeladen und selbst übersetzt werden. Die Installation ist mit einem simplem make ; make install erledigt.
Dabei bleiben allerdings einige Programme unberücksichtigt: btrfs-image erzeugt ein Image eines Btrfs, das alle Metadaten, aber keine Daten enthält – solche Images kann man im Fall von Fehlern zur Analyse an die Btrfs-Entwickler schicken. btrfstune aktiviert oder deaktiviert ein eher exotisches Feature, das so genannte Seeding – damit kann man ein neues Btrfs anlegen, das gleich eine nur lesbare Kopie des Inhalts eines anderen Btrfs enthält. Sinnvoll könnte das beispielsweise sein, um mehrere virtuelle Maschinen mit identischer Grundkonfiguration auf verschiedenen Dateisystemen einzurichten – vermute ich.
btrfs-convert erlaubt es, ein Ext3-Dateisystem nach Btrfs zu konvertieren. Das Tool erstellt eine Kopie der Ext3-Metadaten im Btrfs-Format, wobei die Ext3- und die Btrfs-Metadaten zunächst auf die gleichen Datenblöcke verweisen. Aufgrund des Copy-on-Write-Mechanismus belegen Schreiboperationen im Btrfs neue Datenblöcke, sodass das Ext3-Dateisystem konsistent bleibt (Details dazu finden sich im Btrfs-Wiki). Zum Übersetzen werden die Headerfiles der libacl und der e2fslibs benötigt.
Wenn man btrfs-image, btrfstune und convert im Makefile zu der Variable progs hinzufügt, werden diese Programme anstandslos mit übersetzt.
Und los!
Zum Anlegen eines Btrfs-Dateisystem reicht ein simples
mkfs.btrfs /dev/sda5
Beim Anlegen lassen sich über Optionen die Größe von Knoten und Blättern setzen – der Default (Größe der Speicherseiten, also 4 KByte) erscheint erst einmal vernünftig.
Mann kann ein Btrfs-Dateisystem auch über mehrere Volumes anlegen:
mkfs.btrfs /dev/sdb /dev/sdc
Standardmäßig spiegelt Btrfs die Metadaten über die angegebenen Volumes, während die Daten über die Volumes verteilt werden (Striping). Detailliert steuern lässt sich das über die Optionen -m (Metadaten) und -d (Daten); mögliche Werte sind jeweils raid0 (Striping), raid1 (Mirroring) und raid10. Für Metadaten gibt es zusätzlich single – dann werden die Metadaten nicht dupliziert (standardmäßig speichert Btrfs die Metadaten auch auf einem Device doppelt).
Die Integration des Volume Managememt in das Dateisystem ermöglicht es, alle Daten und Metadaten über Checksummen nicht nur abzusichern, sondern fehlerhafte Daten auch gleich zu korrigieren, sofern ein RAID-1 oder RAID-10 aufgesetzt ist. Würde man, wie es die reine Lehre der sauber getrennten Layer fordert, den Linux-Device-Mapper verwenden, wäre eine solche Korrektur bei schleichender Datenkorruption sehr viel schwieriger.
Und wie mountet man ein solches RAID? Schließlich existiert für das RAID kein eigenes Device. Auch ganz einfach: Wenn irgendeines der Devices gemountet wird, bindet das Btrfs beide Devices in der angegeben Konfiguration ein. Nach einem Reboot (oder dem Entladen des btrfs-Moduls) muss zuvor allerdings einmal
btrfsctl -a
laufen. Der Befehl scannt alle Devices und ermittelt, welche davon in welcher Konfiguration für ein Btrfs genutzt werden. Wer selbst den Überblick verloren hat:
btrfs-show
zeigt diese Information im Klartext an.
Zum Hinzufügen und Entfernen zusätzlicher Volumes dient der Befehl btrfs-vol. Der muss auf einem gemounteten (!) Dateisystem (im Beispiel /mnt/btrfs) ausgeführt werden:
btrfs-vol -a /dev/sdd /mnt/btrfs
Um die Daten im Dateisystem auch auf das neue Device zu verteilen, dient der Befehl
btrfs-vol -b /mnt/btrfs
Entfernt wird ein Device mit
btrfs-vol -r /dev/sdd /mnt/btrfs
Das Tool sorgt dafür, dass zuvor alle Daten auf dem zu entfernenden Device auf die anderen Volumes kopiert werden.
Und wenn eine Platte im RAID-1 kaputt geht? Dann verweigert Btrfs zunächst das Mounten. Mit einer Mount-Option klappt es trotzdem:
mount -o degraded /dev/sdb /mnt/btrfs
Jetzt kann man die kaputte Platte mit btrfs-vol -r entfernen und eine neue hinzufügen.
Defragmentiert wird ein Dateisystem mit
btrfsctl -d /mnt/btrfs
– auch hier ist der Mount-Point, nicht das Device anzugeben. Es ist allerdings keineswegs nötig, immer das komplette Dateisystem zu defragmentieren: Ebenso lässt sich hier eine einzelne Datei oder ein Unterverzeichnis defragmentieren.
