12.3.1 Btrfs-Dateisystem

Das Btrfs-Dateisystem bietet besondere Funktionalitäten, wie z.B. Unterlaufwerke („Subvolumes“), die eine detailliertere Erklärung verdienen. Im folgenden Abschnitt wird versucht, grundlegende sowie komplexe Anwendungsmöglichkeiten eines Btrfs-Dateisystem für Guix System abzudecken.

Im einfachsten Fall kann ein Btrfs-Dateisystem durch einen Ausdruck wie hier beschrieben werden:

(file-system
  (mount-point "/home")
  (type "btrfs")
  (device (file-system-label "my-home")))

Nun folgt ein komplexeres Beispiel, bei dem ein Btrfs-Unterlaufwerk namens rootfs benutzt wird. Dessen Eltern-Btrfs-Dateisystem wird mit my-btrfs-pool bezeichnet und befindet sich auf einem verschlüsselten Gerät (daher die Abhängigkeit von mapped-devices):

(file-system
  (device (file-system-label "my-btrfs-pool"))
  (mount-point "/")
  (type "btrfs")
  (options "subvol=rootfs")
  (dependencies mapped-devices))

Manche Bootloader, wie zum Beispiel GRUB, binden von einer Btrfs-Partition zuerst beim frühen Boot („early boot“) nur die oberste Ebene ein und verlassen sich darauf, dass ihre Konfiguration den korrekten Pfad samt Unterlaufwerk innerhalb dieser obersten Ebene enthält. Auf diese Weise arbeitende Bootloader erzeugen ihre Konfiguration normalerweise auf einem laufenden System, auf dem die Btrfs-Partitionen bereits eingebunden sind und die Informationen über die Unterlaufwerke zur Verfügung stehen. Zum Beispiel liest grub-mkconfig, der bei GRUB mitgelieferte Befehl zur Erzeugung von Konfigurationsdateien, aus /proc/self/mountinfo, um festzustellen, was auf oberster Ebene der Pfad zum Unterlaufwerk ist.

Guix System hingegen erzeugt eine Bootloader-Konfiguration mit der Betriebssystemkonfiguration als einzige Eingabe. Daher muss der Name des Unterlaufwerks, auf dem sich /gnu/store befindet (falls Sie eines benutzen) aus derselben Betriebssystemkonfiguration kommen. Um das besser zu veranschaulichen, betrachten Sie ein Unterlaufwerk namens „rootfs“, das die Daten des Wurzeldateisystems speichert. In einer solchen Situation würde der GRUB-Bootloader nur die oberste Ebene der Wurzel-Btrfs-Partition sehen, z.B.:

/                   (oberste Ebene)
├── rootfs          (Unterlaufwerk als Verzeichnis)
    ├── gnu         (normales Verzeichnis)
        ├── store   (normales Verzeichnis)
[…]

Deswegen muss der Name des Unterlaufwerks dem /gnu/store-Pfad des Kernels, der initrd und jeder anderen Datei vorangestellt werden, die die GRUB-Konfiguration referenziert und während des frühen Boots gefunden werden können muss.

Das nächste Beispiel zeigt eine verschachtelte Hierarchie aus Unterlaufwerken und Verzeichnissen:

/                   (oberste Ebene)
├── rootfs          (Unterlaufwerk)
    ├── gnu         (normales Verzeichnis)
        ├── store   (Unterlaufwerk)
[…]

Dieses Szenario würde ohne Einbinden des „store“-Unterlaufwerks funktionieren. „rootfs“ genügt, weil der Name des Unterlaufwerks dem dafür vorgesehenen Einhängepunkt in der Dateisystemhierarchie entspricht. Alternativ könnte man das „store“-Unterlaufwerk durch Festlegen der subvol-Option auf entweder /rootfs/gnu/store oder rootfs/gnu/store verwenden.

Abschließend folgt ein ausgeklügelteres Beispiel verschachtelter Unterlaufwerke:

/                           (oberste Ebene)
├── root-snapshots          (Unterlaufwerk)
    ├── root-current        (Unterlaufwerk)
        ├── guix-store      (Unterlaufwerk)
[…]

Hier stimmt das „guix-store“-Unterlaufwerk nicht mit dem vorgesehenen Einhängepunkt überein, daher muss es eingebunden werden. Das Unterlaufwerk muss vollständig spezifiziert werden, indem sein Dateiname an die subvol-Option übergeben wird. Eine Möglichkeit wäre, das „guix-store“-Unterlaufwerk als /gnu/store über eine solche Dateisystemdeklaration einzubinden:

(file-system
  (device (file-system-label "btrfs-pool-1"))
  (mount-point "/gnu/store")
  (type "btrfs")
  (options "subvol=root-snapshots/root-current/guix-store,\
compress-force=zstd,space_cache=v2"))