Seite 3: Snapshots, Subvolumes, Performance

Inhaltsverzeichnis

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 zu vergleichen. Dabei schlägt sich Btrfs mehr als ordentlich:

Performance bei großen Dateien
	Ext31	Ext41	Btrfs2
Anlegen von acht Dateien à 1 GByte
Zeit	155,9 s	145,1 s	120,6 s
Durchsatz beim Schreiben	55,4 MByte/s	59,3 MByte/s	68,5 MByte/s
Löschen von acht Dateien à 1 GByte
Zeit	11,87 s	0,33 s	0,63 s
10.000 zufällige Lese- und Schreiboperationen in 8 GByte
Operationen/s	80,0	88,7	115,2

¹ 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) (odi)