Ein Statusbericht zu zehn Jahren BTRFS

Die Welt am Faden

Udo Seidel

Als BTRFS 2008 die Manege der Dateisysteme betrat, galt es als Next Generation File System für Linux. Ein Jahrzehnt später ist der Hype verflogen und es lohnt sich ein Blick auf die aktuelle Situation.

In der Anfangszeit gab es mehrere Erklärungen, was die Abkürzung BTRFS bedeutet. Manche sprachen vom Better File System (also einem besseren Dateisystem) und andere vom B-Tree File System. Beide ergeben Sinn, wenn auch aus unterschiedlichen Gründen. Das neue Dateisystem hatte sich als Ziel gesetzt, bestimmte Mängel von ExtFS und Co. zu beheben und vorhandene Lücken zu schließen. Da wären beispielsweise die verbesserte Datenintegrität durch den Einsatz von Prüfsummen oder das effizientere Nutzen von Festplatten durch transparente Komprimierung. Es liegt also nahe, vom „besseren“ Dateisystem zu sprechen.

Die alternative Ausschreibung von BTRFS hat einen technischen Hintergrund. Die interne Struktur des Dateisystems basiert auf dem Konzept der B-Bäume. Diese Idee stellte der IBM-Mitarbeiter Ohad Rodeh auf der USENIX-Konferenz 2007 vor. Prinzipiell war die Verwendung dieser Baumstrukturen in Dateisystemen nicht neu. Sowohl XFS als auch das damals recht verbreitete ReiserFS verwenden B-Bäume. Chris Mason, damals bei SUSE angestellt, gefiel Rodehs Idee. Er begann, an einem ausschließlich auf diesen Baumstrukturen beruhenden Dateisystem zu arbeiten. 2011 schaute sich die iX-Redaktion BTRFS genauer an. Im Artikel „Datenmobile“ sind Konzept, Design und weitere Interna nachzulesen [1]. Dieser Artikel konzentriert sich auf die Entwicklung der letzten sieben Jahre.

Zunächst ein wenig Theorie

Hier noch einmal im Schnelldurchlauf die zentralen Punkte bei BTRFS. Es ist ein vollwertiges 64-Bit-Dateisystem und benutzt zum Adressieren der Daten Extents – Bereiche aufeinanderfolgender Datenblöcke –, die es über die genannten Baumstrukturen verwaltet. BTRFS hält diese Extents normalerweise entweder ausschließlich für Metadaten oder für Daten vor. Eine Vermischung ist nicht vorgesehen. Das Dateisystem benutzt die Copy-on-Write-Technik (COW). Dabei überschreiben geänderte Daten nicht die alten, sondern wandern in neu allozierte Blöcke. Den Abschluss der Aktion bildet das Aktualisieren der Metadaten, die nun auf die neuen Blöcke zeigen.

BTRFS verwendet einen ganzen Satz von B-Bäumen. Für die bessere Vergleichbarkeit mit Dokumentation im Internet greift dieser Artikel auf die englischen Bezeichner zurück. Beim Blick unter die Motorhaube findet der BTRFS-Interessent beispielsweise den Root Tree, den Filesystem Tree, den Log Tree, den Extent Allocation Tree, den Data Relocation Tree und noch viele mehr. Quasi für jede größere Aufgabenkategorie existiert ein entsprechender Baum. Mit dem Extent Allocation Tree verwaltet das Dateisystem den von Extents belegten Platz. Anwender sehen den Filesystem Tree.

Ein herausstechendes Merkmal von BTRFS ist, dass es mehrere Dateisysteme pro Volume verwalten kann. Für den Benutzer sieht es aus, als könnte man Unterverzeichnisse eines bestehenden Dateisystems separat mounten, und dort getätigte Änderungen sind transparent. Intern organisiert BTRFS solche verschachtelten Dateisysteme als Subvolumes. Mit derselben Technik realisiert das Dateisystem das Speichern von Zwischenständen (Snapshots) – hier in der beschreibbaren Ausführung. Gerade beim Installieren großer Programme, bei Aktualisierungen oder vielen Veränderungen haben sich solche Snapshots bewährt. Funktioniert etwas nicht wie gewünscht, kann man den Ursprungszustand durch Rückkehr auf die „vorige Version“ des Dateisystems wiederherstellen.

BTRFS-Einmaleins

BTRFS benutzt Extents zum Adressieren der Datenblöcke. Diese fasst es zu Blockgruppen variabler Größe zusammen. Typischerweise befinden sich in einer Blockgruppe nur Extents, die gleichartige Daten enthalten, also entweder nur Daten- oder Metadaten-Extents. Die Verwaltung erfolgt über den B-Baum Extent Allocation Tree. Intern arbeitet BTRFS eigentlich mit nur drei verschiedenen Datenstrukturen: Schlüssel (btrfs_key), Block-Header (btrfs_header) und Typenelemente (btrfs_item).

Intern arbeitet BTRFS mit mehreren B-Bäumen (Abb. 1).

Im Block-Header speichert BTRFS beispielsweise die ID des Dateisystems, zu dem der Block gehört, eine Prüfsumme, eine Referenz auf den Zeitpunkt des Einfügens in den Baum und den Level des Blocks in der Struktur. In den Blättern des B-Tree folgt auf den Block-Header das Typenelement. Die Nicht-Blatt-Knoten enthalten nach dem Header nur Schlüssel und Verweise auf weitere Blöcke. Der Schlüssel – der Index in der Baumstruktur – enthält unter anderem eine eindeutige Objekt-ID. Für jeden Datentyp (Inodes, Extent, Verzeichnis …) speichert BTRFS die zugehörigen Daten im gleichen Blatt der Baumstruktur ab. Dabei sind die Schlüsselwerte selbst von vorne anwachsend abgelegt, die zugehörigen Daten legt das Dateisystem von hinten anwachsend ab (siehe Abbildung 1).

Erwartungsgemäß benutzt BTRFS zum Verwalten der physischen Datenträger eine Baumstruktur. Zunächst fasst es die „Festplatten“ in einem Datenpool zusammen und unterteilt diese in sogenannte Chunks mit einer Größe von mindestens 256 MByte. Der zugehörige B-Baum heißt dann auch Chunk Tree. Die Chunks dienen als Abstraktionsschicht der Extents vom physischem Setup. Im Unterschied zu traditionellen Dateisystemen gibt es bei BTRFS also keine Blocklisten, sondern Verweise auf Chunks. Letztere sind auch die kleinste Verwaltungseinheit der BTRFS-RAID-Funktion.

Streng genommen greift die Bezeichnung Dateisystem für BTRFS zu kurz. Im Gegensatz zu seinen Mitspielern kann es mehr als einen Datenträger transparent verwalten. Dies ist typischerweise die Aufgabe eines Volume-Managers und nicht des darüberliegenden Dateisystems. Dieser Ansatz hat nicht nur Befürworter – allerdings hat er sich in der SUN/Oracle-Welt in der Form von ZFS erfolgreich etabliert. 2011, als iX BTRFS vorstellte, beherrschte es die RAID-Modi 0 und 1. Sowohl Daten als auch Metadaten können gespiegelt oder über die Datenträger verteilt sein. Weitere Infos hält der Kasten „BTRFS-Einmaleins“ bereit.

Seit Version 2.6.29 gehört BTRFS zum Auslieferungsumfang des Linux-Kernels. Zunächst war es dort noch als „experimentell“ markiert. Seit 2013/2014 gelten die Basisfunktionen aber als stabil. Es gab dazu keine große Ankündigung, stattdessen verschwanden nach und nach die entsprechenden Hinweise in den Hilfeseiten des Kernels und der Programme im User-Space. Maßgeblich für das Ablegen des „experimentellen“ Status war die Tatsache, dass die Repräsentation auf dem physischen Datenträger (On-Disk-Format) als stabil galt.