Eine erfolgreiche Konvertierung des Root-Dateisystems beginnt mit einem Reboot in eine Rettungsumgebung, wie sie beispielsweise auf einer Ubuntu Installations-CD zu finden ist. Dort fehlt jedoch das Kommando »btrfs-convert
«
. Daher sollte man es vor dem Reboot des Systems nach »/boot
«
kopieren, das ja üblicherweise eine eigene Partition ist. Durch eine Änderung des Eintrages für das Root-Dateisystem in »/etc/fstab
«
von »ext4
«
nach »btrfs
«
steht einem erfolgreichem Restart nur noch die erfolgreiche Konvertierung im Wege. Einmal in die Rettungsumgebung gestartet, kann statt des Root-Dateisystems die Boot-Partition eingehängt werden, um an das Konvertierungstool zu gelangen. Dann folgt ein »fsck
«
des ursprünglichen Dateisystems gefolgt von der Konvertierung und einem Neustart in das konvertierte System (siehe Abbildung 8).
Nach dem Start des Systems sieht das frisch konvertierte Btrfs als Root-Dateisystem oberflächlich betrachtet recht unverdächtig aus, bei genauerem Hinsehen stellt sich aber heraus, dass hier einiges passiert ist (siehe Abbildung 9). Auffallend an diesem konvertierten Dateisystem ist auch die fehlende Metadaten-Redundanz.
Das ist die perfekte Gelegenheit, den Umgang mit mehreren Blockgeräten, auch Pooling genannt, auszutesten. Noch dazu sollen nicht nur die Metadaten, sondern auch die Benutzer-Daten via RAID 1 vor Fehlern einzelner Blockgeräte aber auch vor zufälliger Datenkorruption geschützt werden.
Wie würde die Erweiterung eines Dateisystems um eine Festplatte im Fall von LVM aussehen? Mit LVM-Werkzeugen wäre dazu zuerst ein neues Blockgerät oder wenigstens eine Partition für den Gebrauch als Physical Volume zu definieren. Dieses Physical Volume müsste dann zu einer Volume Group hinzugefügt werden. Abschließend könnte ein Filesystem auf einem Logical Volume vergrößert oder auf einem neuen Logical Volume angelegt und eingehängt werden.