Je suis peut-être pas à jour, mais j’utilise LVM pour la simplicité pour redimensionner les volumes logiques sur la partition. Je me suis pas renseigner des fonctions du BTRFS dans le domaine. C’est possible que c’est une surcouche inutile.
Avec LVM, tu peux en effet redimensionner les volumes logiques plus facilement que s’il s’agissait d’une partition, car sur le disque, il n’est pas utilisé de la même façon. C’est un des avantage de LVM par rapport à un schéma de partitionnement classique.
Dans le cas du tutoriel que tu rédiges, tu ne fais qu’une seule partition. Cette partition est divisée en “subvolumes” BTRFS. Avec des sous-volumes, l’espace est mutualisé et tu ne possèdes au final qu’une seule “partition”. En remplissant de données le sous-volume @home, tu diminues l’espace disponible de @ où se trouve ta racine.
Par conséquent, la couche LVM ici est inutile.
Je ne suis pas certain que faire sans améliore les performances du système de manière significative, mais cette surcouche ajoute une coomplexité, sans ajouter de fonctionalités en soi, d’autant plus que les “volumes logiques” et “partitions” sont sur un volume chiffré.
Par contre, sur un système sans chiffrement, je pense que les bénéfices de BTRFS (par rapport à LVM+BTRFS) est important car BTRFS pourra positionner les données directement comme il l’entend sur le disque à l’emplacement physique adéquat.
Petite question : quel est l’intérêt de mettre du btrfs dans lvm ?
Sachant que tu peux mettre un système de fichier directement sur le volume LUKS (tout comme le pv a été créé sur celui-ci) et qu’il n’y a pas de “partition” swap.
Un LVM avec qu’un seul LV semble un peu inutile, je n’ai pas saisi pourquoi cette complexité.
Sachant que BTRFS va supporter les éventuelles fonctions que LVM permet déjà (comme les snapshots ou le “raid” logiciel)
Je suis peut-être pas à jour, mais j’utilise LVM pour la simplicité pour redimensionner les volumes logiques sur la partition. Je me suis pas renseigner des fonctions du BTRFS dans le domaine. C’est possible que c’est une surcouche inutile.
Avec LVM, tu peux en effet redimensionner les volumes logiques plus facilement que s’il s’agissait d’une partition, car sur le disque, il n’est pas utilisé de la même façon. C’est un des avantage de LVM par rapport à un schéma de partitionnement classique. Dans le cas du tutoriel que tu rédiges, tu ne fais qu’une seule partition. Cette partition est divisée en “subvolumes” BTRFS. Avec des sous-volumes, l’espace est mutualisé et tu ne possèdes au final qu’une seule “partition”. En remplissant de données le sous-volume @home, tu diminues l’espace disponible de @ où se trouve ta racine. Par conséquent, la couche LVM ici est inutile. Je ne suis pas certain que faire sans améliore les performances du système de manière significative, mais cette surcouche ajoute une coomplexité, sans ajouter de fonctionalités en soi, d’autant plus que les “volumes logiques” et “partitions” sont sur un volume chiffré. Par contre, sur un système sans chiffrement, je pense que les bénéfices de BTRFS (par rapport à LVM+BTRFS) est important car BTRFS pourra positionner les données directement comme il l’entend sur le disque à l’emplacement physique adéquat.
Petite question : quel est l’intérêt de mettre du btrfs dans lvm ? Sachant que tu peux mettre un système de fichier directement sur le volume LUKS (tout comme le pv a été créé sur celui-ci) et qu’il n’y a pas de “partition” swap. Un LVM avec qu’un seul LV semble un peu inutile, je n’ai pas saisi pourquoi cette complexité. Sachant que BTRFS va supporter les éventuelles fonctions que LVM permet déjà (comme les snapshots ou le “raid” logiciel)