zurück zum Artikel

Btrfs, das designierte "Next Generation Filesystem" für Linux, bietet eine Reihe von Features, bei denen die anderen Linux-Dateisysteme passen müssen – und erweist sich schon als fast praxistauglich.

Btrfs ist das Dateisystem der Zukunft für Linux, glaubt man den zahlreichen in den letzten Monaten erschienenen Artikeln zum Thema. Und auch die Dateisystementwickler sind dieser Meinung: Btrfs soll das "Next Generation Filesystem" für Linux [1] werden. Allgemeiner Tenor (nicht so sehr der Entwickler, aber der anderen Btrfs-Apologeten): Btrfs ist das ZFS für Linux (so beispielsweise das Linux Magazine [2]). Kann man sicher drüber streiten (ZFS ist bereits im Produktiveinsatz, Btrfs noch hochgradig experimentell), aber Tatsache ist, dass die beiden Dateisysteme eine Menge gemeinsam haben (nähere Informationen zu ZFS bietet der Artikel OpenSolaris als Fileserver [3]). Mit integriertem Volume Management, Checksummen zur Absicherung der Daten, Copy on Write und Snapshots bietet Btrfs eine Sammlung von Features, über die derzeit keines der produktiv nutzbaren Dateisysteme für Linux verfügt.

Btrfs, das im Englischen sowohl als ButterFS als auch als BetterFS ausgesprochen wird, steht ursprünglich für B-Tree FS, da das Dateisystem Daten und Metadaten in Baumstrukturen verwaltet. Seit Linux 2.6.29 [4] ist das Dateisystem, federführend entwickelt von dem bei Oracle angestellten Chris Mason, Teil des Linux-Kernels. Stabil oder gar zur Verwendung auf Produktivsystemen geeignet ist es damit allerdings noch nicht: Wie schon die Btrfs-Seite [5] auf kernel.org deutlich macht, steht noch nicht einmal das Format der Datenstrukturen auf der Platte endgültig fest.

Aber in einem Interview [6] mit Amanda McPherson von der Linux Foundation [7] gibt Mason einen Ausblick, wie es mit Btrfs weitergeht: In der gerade erschienenen [8] ersten Vorabversion des Kernels 2.6.31, so Mason, habe man die meisten Performance-Engpässe beseitigt (die in der letzten Zeit erschienen umstrittenen Performance-Vergleich beispielsweise von Phoronix [9] zwischen Btrfs und anderen Linux-Dateisystemen sind damit also weitgehend hinfällig). Mit dem Kernel 2.6.32, so Mason, sollte Btrfs in einem Zustand sein, in dem es Early Adopters bereits ernsthaft testen können.

Zeit also, einen Blick auf das Linux-Dateisystem der nächsten Generation zu werfen.

Für die Zukunft gerüstet

Als 64-Bit-Dateisystem adressiert Btrfs bis zu 16 Exabyte (16.384 Petabyte) – sowohl als maximale Volume- als auch als maximale Dateigröße. Das ist deutlich mehr als Ext4 [10] (1024 PByte / 16 TByte), liegt gleichauf mit Suns ZFS und bietet reichlich Reserven für die nächsten Jahre. (Nur zum Vergleich: Für den Large Hadron Collider (LHC) am CERN, dem derzeit wohl größten Datenerzeuger der Welt, stehen rund 20 PByte Speicherplatz zur Verfügung – in einem über elf Rechenzentren in Europa, Nordamerika und Asien verteilten Grid [11]).

Auch eine Reihe weiterer konzeptioneller Btrfs-Eigenschaften erinnern an ZFS:

• Btrfs speichert Metadaten und Datenblöcke in zwei Baumstrukturen – eine für die Verzeichnis- und Dateinamen und eine zweite für die Datenblöcke.

• Datenblöcke werden über Extents statt über Blocklisten angesprochen, was die Performance vor allem bei großen Dateien erhöht (Details zu Extents finden sich in dem Artikel Das Linux-Dateisystem Ext4 [12]). Kleine Dateien kann Btrfs direkt in den Blättern des Baums speichern; das vermeidet den Overhead, den Extents für kleine Dateien mit sich bringen.

• Btrfs verwendet Copy on Write: Geänderte Daten schreibt Btrfs in neue Datenblöcke, sodass die alten Daten erhalten bleiben. Erst nach dem Schreiben der Daten wird der Baum zu den Daten aktualisiert – bis dahin zeigt der Datei-Eintrag auf die alten Datenblöcke. Copy on Write lässt sich über die Mount-Option nodatacow abschalten.

• Dabei arbeitet Btrfs in einer Art "data=ordered"-Modus, der dafür sorgt, dass Änderungen an den Metadaten erst vorgenommen werden, nachdem die zugehörigen Daten auf die Platte geschrieben sind. Das stellt sicher, dass nach einem Systemabsturz oder Stromausfall in scheinbar bereits geschriebenen Dateien nicht alte Daten auftauchen, die vorher in den für diese Datei vorgesehenen Datenblöcken gespeichert waren.

• Copy on Write ermöglicht das Erstellen von beschreibbaren Snapshots.

• RAID-Funktionen sind bereits eingebaut (derzeit allerdings nur RAID-0, RAID-1 und RAID-10). Devices lassen sich dabei im laufenden Betrieb hinzufügen und entfernen. Was noch fehlt: RAID-5 und RAID-6 mit ein beziehungsweise zwei redundanten Platten..

• Mehrere Dateisysteme können auf einem Volume (einer Partition) als so genannte Subvolumes ineinander geschachtelt werden – Btrfs enthält sozusagen einen Logical Volume Manager.

• Checksummen sichern die Metadaten- und Datenblöcke ab, fehlerhafte Daten lassen sich so erkennen und – falls ein RAID-1 oder RAID-10 konfiguriert ist – von dem Mirror korrigieren. Dieses Verhalten lässt sich über die Mount-Option nodatasum abschalten.

Daneben bietet Btrfs diverse Features, die man von einem modernen Dateiysystem erwartet:

• Btrfs legt Inodes dynamisch nach Bedarf an; es gibt keine statischen Inode-Tabellen, die bereits beim Erzeugen des Dateisystems geschrieben werden.

• Das Dateisystem lässt sich im laufenden Betrieb vergrößern und verkleinern und defragmentieren.

• Btrfs unterstützt Access Control Lists (ACLs) nach dem POSIX-Standard.

• Dateien können beim Schreiben komprimiert werden (Mount-Option compress). Eine Verschlüsselung der Daten on the fly ist geplant.

Praxis

Praxis

Die gerade erschienene erste Vorabversion des kommenden Kernels 2.6.31 [13] 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 [14]. 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 [15] 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 [16]). 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.

Snapshots, Subvolumes, Performance

Snapshots und Subvolumes

Snapshots und Subvolumes sind im Prinzip dasselbe: ein eigener "Subvolume Tree" innerhalb des "Mutter"-Dateisystems. Genau gesagt enthält bereits das mit mkfs.btrfs angelegte Dateisystem ein Subvolume: Beim Erzeugen eines neuen Btrfs auf einem Volume wird automatisch ein Subvolume "default" angelegt, das – solange keine weiteren Subvolumes oder Snapshots existieren – das gesamte Dateisystem belegt. Snapshots sind letztlich nur Subvolumes, die (anfangs) auf den gleichen Verzeichnis- und Dateibaum Baum zeigen wie das Original-Subvolume.

Einen Snapshot eines Dateisystems legt man in Sekundenbruchteilen mit dem Befehl

btrfsctl -s Name Mount-Point

an, also beispielsweise

btrfsctl -s /mnt/btrfs/snap /mnt/btrfs

Der Snapshot ist anschließend über das Verzeichnis /mnt/btrfs/snap zugänglich; das Verzeichnis wird beim Erzeugen des Snapshots angelegt.

Nach Anlegen eines Snapshots verweisen sowohl das Original-Dateisystem als auch der Snapshot auf dieselben Datenblöcke: Nach dem Anlegen eines Snapshots zeigt du -s (das lediglich alle Dateigrößen in einem Verzeichnisbaum addiert) doppelt so viel belegten Platz an wie df. Wenn man nun Dateien im Original-Dateisystem oder im Snapshot ändert, werden die alten Datenblöcke nach dem Schreiben der neuen Daten nicht freigegeben, sondern für das jeweils andere Dateisystem aufgehoben – erst jetzt steigt die Plattenbelegung tatsächlich an. Snapshots belegen daher nur so viel Speicherplatz auf der Platte, wie Daten im Original-Dateisystem oder im Snapshot geändert werden.

Ein Subvolume legt man mit dem Befehl

btrfsctl -S subvol1 /mnt/btrfs

an. Dabei wird das Verzeichnis /mnt/btrfs/subvol1 angelegt, über das das Subvolume zugänglich ist.

Der Admin muss sich um angelegte Snapshots oder Subvolumes nicht weiter kümmern: Btrfs merkt sich die Strukturen auch über einen Neustart hinweg. Da die Standard-Linux-Tools allerdings nichts von Subvolumes innerhalb eines Dateisystems wissen und die Btrfs-Entwickler (noch) keine eigenen Tools dafür bereitstellen, gibt es derzeit keine Möglichkeit, den Füllungsgrad eines Subvolumes oder Snapshots zu erfahren, zu überprüfen, ob ein Btrfs Subvolumes und Snapshots enthält oder auch nur zu erkennen, ob sich hinter einem Unterverzeichnis ein Snapshot oder ein Subvolume verbirgt. Immerhin: Der Befehl

btrfs-debug-tree /dev/sda2|grep -A1 ROOT_REF

fischt die Namen der Subvolumes und Snapshots in dem Btrfs auf /dev/sda2 heraus.

Zudem ist es uns nicht gelungen, einen Snapshot oder ein Subvolume zu löschen: Zwar lassen sich alle Dateien im entsprechenden Verzeichnis löschen, der dadurch belegte Platz wird dabei auch freigegeben, das Verzeichnis selbst widersetzt sich aber hartnäckig dem Entfernen. Auch btrfsctl kennt keinen Befehl, um einen Snapshot oder ein Subvolume wieder loszuwerden. Diese Unlöschbarkeit übersteht auch einen btrfsck-Lauf und einen Remount.

Performance

Angesichts des recht frühen Entwicklungsstands erscheinen aufwendige Benchmarks mit Postmark, Tiobench etc. noch ein bisschen überkandidelt. Wir haben uns daher darauf beschränkt, exemplarisch den Umgang mit großen Dateien zu stoppen und diese Werte mit den vor kurzem auf dem gleichen Testrechner für Ext3 und Ext4 gemessenen [17] zu vergleichen. Dabei schlägt sich Btrfs mehr als ordentlich:

¹ Mount-Option: noatime; Single User Mode; Dateisystem jeweils frisch gemountet
²Dateisystem jeweils frisch gemountet

Das heißt natürlich nicht, dass Btrfs in allen Anwendungsfällen Ext3 und Ext4 hinter sich lässt – aber es zeigt, dass das Dateisystem eine Menge Potenzial hat, und das nicht nur in Sachen Skalierbarkeit und Managememt, sondern auch bei der Performance. (odi [18]) (odi [19])

URL dieses Artikels:
https://www.heise.de/-221863

Links in diesem Artikel:
[1] https://www.heise.de/news/Kernel-Log-Dateisystem-Ext4-verlaesst-Entwicklungsphase-ein-Zwischenstopp-auf-dem-Weg-zu-btrfs-211446.html
[2] http://www.linux-mag.com/id/7308/
[3] https://www.heise.de/tests/OpenSolaris-als-Fileserver-221631.html
[4] https://www.heise.de/hintergrund/Stetes-Wachstum-Die-Neuerungen-von-Linux-2-6-29-221765.html
[5] http://btrfs.wiki.kernel.org/index.php/Main_Page
[6] https://ldn.linuxfoundation.org/blog-entry/a-conversation-with-chris-mason-btrfs-next-generation-file-system-linux
[7] http://www.linuxfoundation.org
[8] https://www.heise.de/news/Kernel-Log-Hauptentwicklungsphase-von-Linux-2-6-31-abgeschlossen-186083.html
[9] http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1
[10] https://www.heise.de/tests/Das-Linux-Dateisystem-Ext4-221262.html
[11] https://www.heise.de/news/CERN-startet-das-Peta-Grid-209560.html
[12] https://www.heise.de/tests/Das-Linux-Dateisystem-Ext4-221262.html
[13] https://www.heise.de/news/Kernel-Log-Hauptentwicklungsphase-von-Linux-2-6-31-abgeschlossen-186083.html
[14] https://www.heise.de/news/Kernel-Log-Auf-dem-Weg-zu-Linux-2-6-31-188424.html
[15] http://www.kernel.org/pub/linux/kernel/people/mason/btrfs
[16] http://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
[17] https://www.heise.de/tests/Das-Linux-Dateisystem-Ext4-221262.html
[18] mailto:odi@heiseopen.de
[19] mailto:odi@ix.de

Copyright © 2009 Heise Medien