LVM : peut-on unifier/fusionner plusieurs groupes de volume

josephtux · Novembre 10, 2023, 7:54pm

Bonjour,

je crois avoir compris que l’intérêt d’utiliser LVM est son utilisation dans un seul groupe de volume (2 pour du mirrorring ?).

Comme vous êtes nombreux à l’avoir constaté (encore merci pour votre patience), je ne suis pas vraiment compétent pour les taches d’administration.
J’ai donc acheté un nouveau portable (les pros de mon pays n’ose pas l’ouvrir le vieux, vu son état physique, et il commence à agoniser) en demandant au vendeur d’installer Debian et de le configurer

Pour suivre les conseils lus ici de temps en temps, j’ai donc demandé au vendeur d’installer Debian sur 2 SSD en LVM et mirroring.

Par ailleurs, mon installation de Debian (certainement critiquable, mais elle me convient…) est sur 3 partitions:

/ (ext4)
/usr/local/ (ext4 - pour les trucs personnels toutes versions)
/home/work (xfs - pour toutes les données indépendantes des versions)

En commençant à explorer je trouve un éparpillement des volumes que je ne comprends pas.

# pvdisplay | grep 'PV Name'
  PV Name               /dev/nvme0n1p4
  PV Name               /dev/nvme1n1p3
  PV Name               /dev/nvme0n1p3
  PV Name               /dev/nvme1n1p2
  PV Name               /dev/nvme0n1p2
  PV Name               /dev/nvme1n1p1

# vgdisplay  | grep -E 'VG Name|VG Size'
  VG Name               vg_mirror_work
  VG Size               <1,82 TiB
  VG Name               vg_mirror_local
  VG Size               74,50 GiB
  VG Name               vg_mirror_root
  VG Size               149,00 GiB

# lvdisplay | egrep 'Path|Name|Size|Mirrored'
  LV Path                /dev/vg_mirror_work/lv_work
  LV Name                lv_work
  VG Name                vg_mirror_work
  LV Size                930,00 GiB
  Mirrored volumes       2
  LV Path                /dev/vg_mirror_local/lv_local
  LV Name                lv_local
  VG Name                vg_mirror_local
  LV Size                37,00 GiB
  Mirrored volumes       2
  LV Path                /dev/vg_mirror_root/lv_root
  LV Name                lv_root
  VG Name                vg_mirror_root
  LV Size                74,00 GiB
  Mirrored volumes       2

Extraits de fdisk -l:

Périphérique       Début        Fin   Secteurs Taille Type
/dev/nvme0n1p1      2048     976895     974848   476M Système EFI
/dev/nvme0n1p2    976896  157222911  156246016  74,5G LVM Linux
/dev/nvme0n1p3 157227008  235352063   78125056  37,3G LVM Linux
/dev/nvme0n1p4 235352064 2188476415 1953124352 931,3G LVM Linux

Périphérique       Début        Fin   Secteurs Taille Type
/dev/nvme1n1p1      2048  156250111  156248064  74,5G LVM Linux
/dev/nvme1n1p2 156250112  234375167   78125056  37,3G LVM Linux
/dev/nvme1n1p3 234375168 2187499519 1953124352 931,3G LVM Linux

Il n’y a «que» 2 SSD qui semblent divisés en 3 partitions chacun qui deviendront autant de volumes physiques.

Existe-t-il un moyen de réparer cette bizarrerie sans avoir à réinstaller bookworm (je crains d’avoir à chercher des pilotes matériels et autres subtilités de mon point de vue trop shadok (ga bu zo meu).

Les partitions /usr/local et /home/work ne sont pas encore utilisées.

Je suppose qu’il faut supprimer les volumes inutilisés puis recréer les lvm.

Mais je crains d’oublier des étapes ou des précautions… Si le diable est dans les détails, je ne doute pas que ce soit vrai en la matière!

à moins que vous n’ayez un meilleur conseil.

merci pour votre intérêt

loicmtp · Novembre 10, 2023, 8:00pm

Votre systeme marche bien?
Si la réponse est positive alors:

"Don't f.....g touch it!"

josephtux · Novembre 11, 2023, 10:19am

Merci loicmtp

PascalHambourg · Novembre 22, 2023, 5:21pm

Non, dans trois systèmes de fichiers. Les partitions, c’est autre chose.

Et qu’il nous est difficile de comprendre si tu filtres les informations avec grep. Il aurait mieux valu fournir la sortie des commandes lvs, pvs et vgs.
Néanmoins si je comprends bien il y a 3 VG constitués chacun de de 2 PV (1 sur chaque SSD) et occupés chacun en totalité par un LV en RAID1. C’est mauvais, je n’aurais jamais fait ça. Aucune flexibilité, aucun intérêt à utiliser LVM, autant utiliser le RAID1 de mdadm sans LVM. D’autre part une seule partition EFI sur des deux SSD, pas génial pour l’amorçage si c’est ce SSD qui tombe en panne.

J’aurais fait ceci :

une partition EFI indépendante sur chaque SSD
un PV LVM sur chaque SSD
un seul VG regroupant les deux PV
les 3 LV dans le même VG n’occupant pas tout l’espace, laissant de l’espace libre pour les agrandissements futurs.

Pour répondre au titre, la commande vgmerge permet de fusionner deux VG dont au moins un doit être inactif. Je ne l’ai jamais utilisée donc aucun retour d’expérience. Il faudra ensuite modifier toutes les références aux LV pour remplacer le nom des VG fusionnés par le nom du VG restant dans /etc/fstab, l’initramfs, grub.cfg…

Ce n’est pas parce qu’il « marche » à l’instant T qu’il est bien fichu et qu’il répond au besoin. On a l’exemple classique des partitions trop petites ou trop grandes qu’il sera pénible de redimensionner le moment venu.

loicmtp · Novembre 22, 2023, 5:46pm

Hum Hum

« If it ain’t broke, don’t break it »

josephtux · Novembre 25, 2023, 12:14pm

Merci Pascal Hambourg,

100% d’accord avec tout ça.

C’est ce que j’avais demandé au vendeur, sans doute moins clairement (un seul VG, 3LV et mirroring, et 1 partition d’amorçage sur chaque ssd) mais visiblement il semblait ignorer l’intérêt de LVM, tel que vous l’avez très clairement décrit.

C’est pourquoi je demandais ici comment corriger cette installation, tut en préservant l’installation de Bookworm, car je crains la possibilité de particularités matérielles que je ne saurais peut-être pas adapter.

Devant être hospitalisé demain, je serais certainement absent quelques semaines.
Je reviendrai vous solliciter si je récupère mes 7 neurones, avec les pvdisplay, vgdiplay et lvdisplay bizarrement éparpillés (6 PV pour 2 SSD, 6VG pour 3lv en mirroir) et une seule partition EFI

J’étudierai aussi la commande vgmerge

blkid
/dev/mapper/vg_mirror_work-lv_work: UUID=« 9698bb47-9b18-4d8b-973b-d1786ee0ad1a » BLOCK_SIZE=« 512 » TYPE=« xfs »
/dev/nvme0n1p3: UUID=« 3M1TgW-b7i5-YPBs-B3LF-t73P-heEt-d75pAa » TYPE=« LVM2_member » PARTUUID=« f15bb242-42de-4b37-b91e-f42b09a5b42b »
/dev/nvme0n1p1: UUID=« 57E7-29DB » BLOCK_SIZE=« 512 » TYPE=« vfat » PARTUUID=« 3fcec8be-9db3-40fe-8bdb-4b191ac348d3 »
/dev/nvme0n1p4: UUID=« JAJ7QO-z1ej-0Y8o-UVxn-Sc43-QPkE-n5GbLK » TYPE=« LVM2_member » PARTUUID=« 27690379-1cbd-4e5b-88f6-5337ee27bba1 »
/dev/nvme0n1p2: UUID=« eb9aTS-RAqG-YML9-JiBs-r21v-ZVTI-UJabMd » TYPE=« LVM2_member » PARTUUID=« 134805a9-b572-41f4-98bf-3e8897766719 »
/dev/mapper/vg_mirror_local-lv_local_rimage_1: UUID=« d6aff5d6-0a78-4770-9dc5-f81ac90bb429 » BLOCK_SIZE=« 4096 » TYPE=« ext4 »
/dev/mapper/vg_mirror_root-lv_root_rimage_1: UUID=« 26bc0653-a728-479e-be9c-f41dec88e41e » BLOCK_SIZE=« 4096 » TYPE=« ext4 »
/dev/mapper/vg_mirror_work-lv_work_rimage_0: UUID=« 9698bb47-9b18-4d8b-973b-d1786ee0ad1a » BLOCK_SIZE=« 512 » TYPE=« xfs »
/dev/mapper/vg_mirror_root-lv_root_rimage_0: UUID=« 26bc0653-a728-479e-be9c-f41dec88e41e » BLOCK_SIZE=« 4096 » TYPE=« ext4 »
/dev/mapper/vg_mirror_work-lv_work_rimage_1: UUID=« 9698bb47-9b18-4d8b-973b-d1786ee0ad1a » BLOCK_SIZE=« 512 » TYPE=« xfs »
/dev/nvme1n1p2: UUID=« YecTEC-r9TU-C6Md-nZqj-dwRh-EQS6-pPWL2B » TYPE=« LVM2_member » PARTUUID=« 4a023561-6541-49d7-877c-eb3c1d8b34fd »
/dev/nvme1n1p3: UUID=« NLREJs-TVHI-3LQL-3Nhg-lzFi-FUfl-Ab0J5r » TYPE=« LVM2_member » PARTUUID=« b10fe900-6c2a-4486-84b3-38e1cde7c526 »
/dev/nvme1n1p1: UUID=« T7sifw-gTzn-oDNf-EgB2-ekJh-T2pB-BeVueE » TYPE=« LVM2_member » PARTUUID=« 6bb47e78-db28-48a0-8f1a-5c2227ec54e1 »
/dev/mapper/vg_mirror_root-lv_root: UUID=« 26bc0653-a728-479e-be9c-f41dec88e41e » BLOCK_SIZE=« 4096 » TYPE=« ext4 »
/dev/mapper/vg_mirror_local-lv_local_rimage_0: UUID=« d6aff5d6-0a78-4770-9dc5-f81ac90bb429 » BLOCK_SIZE=« 4096 » TYPE=« ext4 »
/dev/mapper/vg_mirror_local-lv_local: UUID=« d6aff5d6-0a78-4770-9dc5-f81ac90bb429 » BLOCK_SIZE=« 4096 » TYPE=« ext4 »

Mon idée serait de supprimer tout ce qui n’est pas bookworm, étendre les 2 PV restant et y installer sur un seul VG les 2 autres LV. Mais le risque est réel de gaffer…

Je devrais d’abord apprendre à faire une sauvegarde du système utilisable pour une réinstallation complète si nécessaire.

J’ai aussi observé une anomalie: quelques scories (?) d’ubuntu, car c’est la distribution qu’ils proposent en général.

Bref du neuf pour un vieux c’est pas magique!

Merci PascalHambourg

Zargos · Novembre 25, 2023, 12:30pm

Normalement, tu devrais avoir:
Une partition EFI sur chaque disque
Une partition LVM sur le reste de chaque disque
Un raid1 entre les deux partition EFI
Un raid1 entre les deux partition LVM.

Ensuite un PV avec la partition LVM
Un VG avec le PV précédent
Les LV qui tu as décidé de mettre dans ton ,LVM, avec à minima:

/
swap
et je te conseille:
/home => Pour les utilisateurs, séparé du reste pour récup éventuelle
/var => qui évolue souvent en fonction de l’utilisation (site web, etc…)
/var/log => pour s’"assurer que les logs ne remplissent pas tout le disque
/var/log/audit => dito le précédent mais pour auditd
/vat/tmp => répertoire temporaire des script des packages par exemple. Mieux vaut isoler avec des droits nodev nosuid
/tmp => idem /var/tmp qui devrait rmême avoir noexec mais certains script de packages mal fait utilise ce répertoire comme repertoire d’execution.

PascalHambourg · Novembre 25, 2023, 2:59pm

Le fait que les SSD soient divisés en plusieurs PV n’est pas un problème en soi puisque LVM permet d’agréger plusieurs PV dans un VG, qu’ils soient sur le même disque ou des disques différents. J’ai juste un doute sur la capacité de LVM d’allouer automatiquement les extents d’un LV RAID dans des PV stockés sur des disques distincts.

Tu veux dire supprimer les LV, VG et PV « local » et « work » pour agrandir les PV « root » puis recréer les LV local et work ? Pourquoi pas, mais à ta place je ne m’embêterai pas à ce point ; je tenterais le merge des deux VG local et work dans root. Eventuellement je réduirais le LV work et son système de fichiers pour avoir de l’espace libre au cas où un des autres LV aurait besoin d’être agrandi, ou bien créer des LV supplémentaires pour un swap par exemple, ça peut toujours servir pour l’hibernation ou un besoin ponctuel.

Je l’ai fait pour tester, ça ne marche pas bien, c’est de la bidouille. Les firmwares UEFI ne supportent pas le format RAID de Linux, donc la seule façon de faire du RAID avec les partitions EFI de façon transparente pour le firmware UEFI est de créer un ensemble RAID1 au format 1.0 (superbloc RAID à la fin, le format par défaut 1.2 plaçant le superbloc RAID au début). Mais le firmware UEFI verra les deux partitions comme indépendantes et il n’est pas garanti qu’il (ou autre chose) n’écrira pas dans une des partitions, brisant la synchronisation silencieusement et causant potentiellement une corruption de données puisque le pilote RAID va piocher indifféremment dans les deux partitions qui n’ont pas le même contenu.

Autre inconvénient, grub-install ne supporte pas l’enregistrement d’un ensemble RAID1 dans les variables de boot EFI. Il faut donc installer GRUB dans le « chemin de support amovible » (qui n’a pas besoin de variable de boot) et/ou créer manuellement les variables de boot avec efibootmgr pour chacune des deux partitions.

J’ai changé mon fusil d’épaule : une partition EFI indépendante sur chaque disque, et installation manuelle de GRUB sur chacune. Ce n’est pas parfait (les paquets grub-efi de Debian ne gèrent pas plusleurs partitions EFI, ceux d’Ubuntu le font mais de façon pas très satisfaisante) mais au moins c’est propre.

Tu veux dire un ensemble RAID1 créé par mdadm et utilisé comme PV LVM ? Ce n’est pas la seule façon de faire du RAID avec LVM, on peut aussi créer des LV RAID directement dans LVM comme cela a été fait ici. Les deux méthodes utilisent les mêmes pilotes md du noyau, ce n’est pas une réimplémentation du RAID par LVM. Personnellement je préfère la méthode « classique » avec mdadm parce que c’est celle que je connais et que je la trouve plus lisible, mais l’autre offre plus de flexibilité ; par exemple elle permet d’utiliser différents niveaux de RAID dans un même VG.

Zargos · Novembre 25, 2023, 5:03pm

Oj’aai fait il y a pas mal de temps. J’ai en fait créé le boot EFI sur un disque et j’ai laissé le raid faire ensuite le reste. Par contre effectivement, il me semble me rappeler du RAID1 format 1.0.

En fait, au départ j’ai créé un raid avec un seul membre. J’y ai installé Debian. Puis j’ai ajouté le deuxième disque aux ensembles. Et j 'ai laissé le RAID faire la synchronisation.

Je n’ai jamais eu de problème depuis 4 ans que ça tourne.
Je n’ai pas vérifier l’état actuel de la partition EFI sur les deux disques.

Quelle serait la commande à utiliser pour faire une vérification des partition EFI sur les deux disques?

Oui effectivement, mais à l’époque les docs n’étaient pas très claire. Donc j’ai fait en mode classique.

PascalHambourg · Novembre 25, 2023, 5:23pm

On peut faire un « scrub » pour vérifier la cohérence des données des membres d’un ensemble RAID1, cf. les pages de manuel de mdadm et md.

Zargos · Novembre 25, 2023, 6:03pm

A priori, si je ne me suis pas trompé je n’ai pas d’incohérence.
/dev/md0 qui est utilisé pour /boot/efi est bien en format 1.0.
/dev/md1 c’est pour la partition LVM.