btrfs - Linux-Dateisystem der Zukunft
Das Dateisystem btrfs ist in Linux 2.6.35 (und 2.6.36) noch keinesfalls ausgereift, aber es stellt in absehbarer Zeit die beste Dateisystem-Wahl für Linux dar. Dieser Artikel stellt die hauptsächlichen Funktionen von btrfs vor.
Wieviel Platz ist noch frei?
Bei anderen Dateisystemen kann ganz einfach mit df -h festgestellt werden, wieviel Speicherplatz vorhanden ist, wieviel davon belegt ist und wieviel noch frei ist. Bei btrfs-Dateisystemen liefert df aber oft vollkommen falsche Ergebnisse, insbesondere im Zusammenhang mit RAID. Leider sind auch die btrfs-Kommandos filesystem show und filesystem df nicht in der Lage, wirklich konkrete Zahlen zu ermitteln, wieviel Speicherplatz noch frei ist.
Das folgende Beispiel soll Ihnen dabei helfen, zumindest die Daten korrekt zu interpretieren, die btrfs liefert. Als Ausgangspunkt dient ein kleines btrfs-RAID-1-System aus zwei je acht GByte großen Partitionen. In dieses Dateisystem wurde das gesamte /usr-Verzeichnis des Testsystems kopiert (Platzbedarf ca. 1,8 GByte).
mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1 mount /dev/sdb1 /media/btrfs cp -r /usr /media/btrfs
btrfs filesystem show verrät, dass das Dateisystem aus zwei jeweils acht GByte großen Devices zusammengesetzt ist. Insgesamt enthält das Dateisysten 1,9 GByte System-, Metadaten und Nutzdaten. Außerdem wissen wir jetzt, dass auf jedem Device jeweils 3,6 GByte Daten reserviert wurden. filesystem show liefert allerdings keine Informationen, wie die Devices miteinander verbunden sind (also welcher RAID-Level aktiv ist). Daher ist es auch unmöglich zu sagen, wie groß die gesamte Kapazität des Dateisystems ist. (Bei RAID-0 würde sie 16 GByte betragen, bei RAID-1 aber nur acht.)
btrfs filesystem show /dev/sdb1 /dev/sdc1 Label: none uuid: dc691a5d-187e-4cb4-a94a-d12dabdffde4 Total devices 2 FS bytes used 1,89GB devid 1 size 8.00GB used 3,63GB path /dev/sdb1 devid 2 size 8.00GB used 3,61GB path /dev/sdc1
btrfs filesystem df gibt Auskunft darüber, wie die reservierten Daten verwendet werden. btrfs hat bisher 2,6 GByte für die eigentlichen Daten reserviert und davon ca. 1,7 GByte tatsächlich genutzt. Weiters hat btrfs ein GByte für Metadaten reserviert und davon knapp 200 MByte genutzt. (Das ist rund ein Achtel der eigentlichen Daten, also verhältnismäßig viel.) Schließlich hat btrfs 12 MByte für Systemdaten reserviert und gerade einmal 4 KByte davon tatsächlich genutzt. 2,61 +1,01 + 0,01 ergibt die 3,63 GByte, die filesystem show angezeigt hat.
btrfs filesystem df /media/btrfs/ Data: total=2.61GB, used=1.70GB Metadata: total=1.01GB, used=198.82MB System: total=12.00MB, used=4.00KB
Wieviel Daten sind nun noch frei? Wir wissen, dass insgesamt 16 GByte Speicherplatz zur Verfügung stehen. Wegen der mit RAID-1 verbunden Redundanz sinkt der nutzbare Speicherplatz auf die Hälfte, also auf acht GByte. Davon sind bereits 3,63 GByte reserviert. Der für die eigentlichen Daten reservierte Bereich kann somit noch maximal um 4,37 GByte vergrößert werden und würde dann knapp 7 GByte betragen. Davon sind 1,7 GByte bereits genutzt. Das ergibt einen freien Speicherplatz für Dateien von ca. 5,3 GByte. Allerdings geht diese Rechnung nur auf, wenn btrfs nicht zwischenzeitlich nochmals Platz für Metadaten reservieren muss.
Ein elementares Problem für btrfs-Administratoren besteht momentan darin, dass sie den RAID-Level des Dateisystems nicht herausfinden können. Das macht die Administration von Dateisystemen, die sie nicht selbst eingerichtet haben, sehr schwierig. Es ist anzunehmen, dass die btrfs-Werkzeuge diesbezüglich noch verbessert werden.
Fazit
Das Arbeiten mit btrfs ist spannend. btrfs bietet beinahe soviele Funktionen wie ext4 plus LVM plus Software-RAID zusammen und ist insofern am ehesten mit Suns (nunmehr Oracles) ZFS zu vergleichen. In diesem Zusammenhang ist auch interessant, dass auch der Btrfs-Hauptentwickler Chris Mason ein Orcale-Mitarbeiter ist! Bis jetzt hat Oracles Sun-Übernahme zum Glück keine negativen Auswirkungen auf den Arbeitseifer von Chris Mason gezeigt, eher im Gegenteil. Lizenzprobleme sind nicht zu befürchten, der btrfs-Treiber untersteht so wie der restliche Kernelcode der GPL.
In Benchmarktests schneidet btrfs noch uneinheitlich ab, manchmal ein wenig besser als ext, manchmal ein wenig schlechter. Die besten Benchmark-Ergebnisse erzielt btrfs in der Regel zusammen mit der compress-Option - ein durchaus verblüffendes Resultat.
Die Fülle an Funktionen macht aber auch skeptisch. Gerade bei Dateisystemen steht die Stabilität an erster Stelle, und hier hapert es noch. Angesichts der Komplexität von btrfs werden wohl eher Jahre (und nicht Monate) vergehen, bevor ich wirklich kritische Daten btrfs anvertraue - auch wenn die btrfs-Entwickler gerade überlegen, ob btrfs in Kernel 2.6.36 als »stabil« gekennzeichnet werden soll.
Autoreninformation
Dieser Artikel aus dem Blog von Michael Kofler erscheint auf Pro-Linux.de mit der freundlichen Genehmigung des Autors.
