11.4.1 Système de fichier Btrfs

Btrfs a des particularités, comme les sous-volumes, qui méritent d’être expliquées plus en détail. La section suivante tente de couvrir les utilisations de base ainsi que les utilisations complexes d’un système de fichiers Btrfs avec le système Guix.

Dans son usage le plus simple, un système de fichier Btrfs peut être décrit, par exemple, par :

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

L’exemple ci-dessous est plus complexe, car il utilise un sous-volume de Btrfs, nommé rootfs. Le système de fichiers Btrfs parent est appelé my-btrfs-pool, et se trouve sur un périphérique crypté (d’où la dépendance à l’égard de mapped-devices) :

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

Certains chargeurs d’amorçage, par exemple GRUB, ne montent une partition Btrfs qu’à son niveau supérieur au début du démarrage, et s’appuient sur leur configuration pour se référer au chemin correct du sous-volume à l’intérieur de ce niveau supérieur. Les chargeurs d’amorçage fonctionnant de cette manière produisent généralement leur configuration sur un système en cours d’exécution où les partitions Btrfs sont déjà montées et où les informations sur les sous-volumes sont facilement disponibles. Par exemple, grub-mkconfig, la commande de générateur de configuration livrée avec GRUB, lit /proc/self/mountinfo pour déterminer le chemin de niveau supérieur d’un sous-volume.

Guix System produit une configuration de bootloader en utilisant la configuration du système d’exploitation comme seule entrée ; il est donc nécessaire d’extraire le nom du sous-volume sur lequel vit /gnu/store (s’il existe) de cette configuration du système d’exploitation. Pour mieux illustrer cela, considérons un sous-volume nommé "rootfs" qui contient les données du système de fichiers racine. Dans une telle situation, le chargeur d’amorçage GRUB ne verrait que le niveau supérieur de la partition Btrfs de la racine, par exemple :

/                   (niveau supérieur)
├── rootfs          (répertoire des sous-volumes)
    ├── gnu         (répertoire normal)
        ├── store   (répertoire normal)
[...]

Ainsi, le nom du sous-volume doit être précédé du chemin /gnu/store du noyau, des binaires initrd et de tout autre fichier mentionné dans la configuration GRUB qui doit être trouvé au début d’amorçage.

L’exemple suivant montre une hiérarchie imbriquée de sous-volumes et de répertoires :

/                   (niveau supérieur)
├── rootfs          (sous-volume)
    ├── gnu         (répertoire normal)
        ├── store   (sous-volume)
[...]

Ce scénario fonctionnerait sans monter le sous-volume « store ». Le montage de "rootfs" est suffisant, puisque le nom du sous-volume correspond à son point de montage prévu dans la hiérarchie du système de fichiers. Une autre solution consiste à faire référence au sous-volume « store » en définissant l’option subvol soit /rootfs/gnu/store soit rootfs/gnu/store.

Enfin, un exemple plus élaboré de sous-volumes imbriqués :

/                           (niveau supérieur)
├── root-snapshots          (sous-volume)
    ├── root-current        (sous-volume)
        ├── guix-store      (sous-volume)
[...]

Ici, le sous-volume « guix-store » ne correspond pas à son point de montage prévu, il est donc nécessaire de le monter. Le sous-volume doit être entièrement spécifié, en passant son nom de fichier à l’option subvol. Par exemple, le sous-volume « guix-store » peut être monté sur /gnu/store en utilisant une déclaration de système de fichiers telle que :

(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"))