Comment redimensionner une partition contenant un unique groupe de volume (LVM)?

[moondump]

Bonjour à tous.
Il y a quelques années, j’ai installé mon système sur l’unique partition de /dev/sda, c’est à dire /dev/sda1. Elle est elle-même sous partitionnée grâce à LVM.

Néanmoins, comme j’ai utilisé la totalité du disque pour cette partition, je n’ai plus de marge de manœuvre pour d’autres besoins. De plus, le gâchis d’espace disque est énorme (90%).

Une solution consisterait repartir de zéro, mais cela serait inélégant et comme cette station doit assurer un service quasi permanent, les ruptures de service doivent être les plus courtes possibles.

Voila la situation :

/!\ : lsblk                                                                                                      
NAME                           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
fd0                              2:0    1     4K  0 disk  
sda                              8:0    0 465,8G  0 disk  
└─sda1                           8:1    0 465,8G  0 part  
  ├─00-Deb--Stretch_v9--Racine 254:0    0   952M  0 lvm   /
  ├─00-Deb--Stretch_v9--usr    254:1    0   3,1G  0 lvm   /usr
  ├─00-Deb--Stretch_v9--boot   254:2    0   476M  0 lvm   /boot
  ├─00-root                    254:3    0   476M  0 lvm   /root
  ├─00-tmp                     254:4    0    14G  0 lvm   /mnt/debinst_buster/tmp
  ├─00-Deb--Stretch_v9--var    254:5    0   2,8G  0 lvm   /var
  ├─00-opt                     254:6    0   284M  0 lvm   /opt
  ├─00-Espace_d_echange        254:7    0   1,9G  0 lvm   [SWAP]
  ├─00-Usr_local               254:8    0    44M  0 lvm   /usr/local
  ├─00-Deb--Buster_v10--Racine 254:12   0     1G  0 lvm   /mnt/debinst_buster
  ├─00-Deb--Buster_v10--boot   254:13   0   200M  0 lvm   /mnt/debinst_buster/boot
  ├─00-Deb--Buster_v10--usr    254:14   0     4G  0 lvm   /mnt/debinst_buster/usr
  └─00-Deb--Buster_v10--var    254:15   0   3,5G  0 lvm   /mnt/debinst_buster/var
sdb                              8:16   0   1,8T  0 disk  
└─sdb_crypt                    254:9    0   1,8T  0 crypt /home
sdc                              8:32   0   3,7T  0 disk  
└─sdc_crypt                    254:10   0   3,7T  0 crypt /mnt/sauvegarde
/!\ : 

Ce je souhaiterais faire, c’est :

• Réduire le VM nommé « 00 » à la taille effective de la somme de
  tous les LV.
• Réduire la partition « sda1 » à la taille du VM déjà cité.
• Créer d’autres partitions (LVM + crypto), progressivement serviront
  à la production (facile).
• À terme, liquider la partition sda1.

Je me demande donc quelle est la meilleure stratégie et les bons outils à utiliser ?

Merci de m’avoir consacré un peu de votre attention.

[PascalHambourg]

Il paraît que Gparted est capable de redimensionner une partition servant de volume physique LVM. Jamais essayé.

Sinon, l’outil de base pour redimensionner un PV est pvresize. Il faudra éventuellement utiliser pvmove préalablement pour déplacer les extents utilisés qui seraient situés au-delà de la nouvelle taille souhaitée. Pour finir il faudra réduire la partition à la nouvelle taille du PV avec parted.

[moondump]

Merci pour ta réponse.

Mais c’est à haut risque de destruction du système : pour lvm, je pense que cela va passer sans problème. Il y plein de tutos à ce sujet sur Internet. Là où je tremble un peu, c’est avec Gparted…

j’ai une fenêtre de tir dans quinze jour… Je vous donnerai des nouvelles à ce sujet.

[PascalHambourg]

Tu peux te faire la main avec un VG de test.

[moondump]

Il paraît que Gparted est capable de redimensionner une partition servant de volume physique LVM.

J’ai oublié une précision importante ! C’est une station sans serveur X. Le paquet « parted » peut être ?

[PascalHambourg]

Comme je l’ai écrit précédemment, parted pourra servir à réduire la partition (commande resizepart - attention : il faut spécifier la nouvelle position de fin et non la nouvelle taille). Mais seulement après avoir réduit la taille du PV avec pvresize.

[moondump]

commande resizepart

OK, merci pour l’info sur la commande. Je crois être maintenant sur de bons rails.

Le D-day dans un peu plus d’une semaine.

[moondump]

Du billard ! Les deux commandes sont passées comme une lettre à la poste.

Merci pour ton aide précieuse !

[moondump]

Juste une précision… j’ai depuis cette manipulation, un message comme suit :
WARNING: Device /dev/xxxx has size of X sectors which is smaller than corresponding PV size of X sectors.

Le problème a été résolu grâce aux réponses apportées à l’adresse :

Sectors which is smaller than corresponding PV size error

Voici ci-après, une capture de cession qui donne corps aux explications :

    root@s04:~# pvresize --setphysicalvolumesize 2928640s /dev/sda1 
  WARNING: Device /dev/sda1 has size of 2928640 sectors which is smaller than corresponding PV size of 250066944 sec
tors. Was device resized?                                                                                          
  One or more devices used as PVs in VG s04_boot have changed sizes.
  Physical volume "/dev/sda1" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized
root@s04:~# vgcfgrestore s04_boot 
  Volume group s04_boot has active volume: Deb-Buster_v10-boot.
  Volume group s04_boot has active volume: Deb-Stretch_v9-boot.
  WARNING: Found 2 active volume(s) in volume group "s04_boot".
  Restoring VG with active LVs, may cause mismatch with its metadata.
Do you really want to proceed with restore of volume group "s04_boot", while 2 volume(s) are active? [y/n]: y
  Restored volume group s04_boot.
root@s04:~#

Depuis, tout semble fonctionner à merveille, mais je me demande quels problèmes cela peut occasionner sur les données…

[PascalHambourg]

@moondump

j’ai depuis cette manipulation, un message comme suit :
WARNING: Device /dev/xxxx has size of X sectors which is smaller than corresponding PV size of X sectors.

Tu as dû faire une erreur dans les tailles passées à pvresize et parted. Peut-être à cause de l’interprétation différente des préfixes multiplicateurs : « G » signifie gibi (giga binaire, 1024^3) pour pvresize et les autre commandes LVM, et giga (décimal, 1000^3, un peu plus petit) pour parted (pour qui gibi s’écrit « Gi »).

@moondump

je me demande quels problèmes cela peut occasionner sur les données

Au mieux, la perte des données située au-delà de la nouvelle taille de la partition. Au pire, la perte de tous les volumes logiques ayant des données situées au-delà de la nouvelle taille.

[Zargos]

@PascalHambourg

Il paraît que Gparted est capable de redimensionner une partition servant de volume physique LVM.

Oui ça fonctionne, je m’en suis servis pas plus tard que la semaine dernière. Il faut par contre s’assurer de ne pas diminuer la partition LVM en dessous de la taille utilisé avec une petite marge sinon les données sont compromises.
gpart en ligne de commande fonctionne très bien.
le principe est le suivant pour recupérer la place:

• retailler les volumes logiques du LVM (lvresize puis resize2fs)
• retailler la partition LVM en fonction de l’espace disque disponible (Gparted)
• créer la partition pour le nouveau LVM (Gparted)
• créer le volume groupe qui va avec (LVM)
• créer le ou les volumes logiques en fonction de la place disponible (LVM)
• déplacer les données de l’ancien au nouveau (shell)
• modifier fstab en conséquence (shell)
• supprimer l’ancien volume logique (LVM)
• retailler l’ancienne partition pour libérer l’espace ainsi libéré (Gparted)
• retailler la nouvelle partition pour récupérer l’espace libéré (Gparted)
  Et ainsi de suite.
  C’est fastidieux si les espace sont très exigus, mais ça marche.

Attention, le fait de libérer de la place va donner un espace de stockage libre à la droite immédiate de la partition modifiée. Donc cela donnerait

| Ancien LVM| -|espace libre|-|Nouveau LVM|

Pour récupérer l’espace libre pour le nouveau LVM, il faut donc déplacer la nouvelle partition LVM à gauche pour ensuite agrandir la partition. Donc plusieurs manip qui peuvent prendre du temps.

Par contre il ne sera pas possible de maintenir efficacement le service pendant la migration.

Attention aux changement liés bien sur à grub et les secteurs de démarrages;

Autre point à prendre en compte, je ne suis pas sur qu’on puisse facilement retaille rune partition crypto. ça je n’ai pas essayer.
Pour la partie crypto, il est peut etre plus sain de faire d’abord le taf en normal pour ensuite convertir la partition en crypto une fois tout terminé.

pvresize modifie les physical volume,
vgresize pour les volume group
lvresize pour les volumes logiques.

Bon, je sais j’arrive un peu après la bataille

[PascalHambourg]

@Zargos

Oui ça fonctionne, je m’en suis servis pas plus tard que la semaine dernière. Il faut par contre s’assurer de ne pas diminuer la partition LVM en dessous de la taille utilisé avec une petite marge sinon les données sont compromises.

Si ça marchait si bien, Gparted ne devrait pas accepter de réduire un PV LVM en-dessous de la taille utilisée.

@Zargos

gpart en ligne de commande fonctionne très bien.

Que je sache, gpart ne sert pas à ça. Tu veux dire gdisk ?

@Zargos

Autre point à prendre en compte, je ne suis pas sur qu’on puisse facilement retaille rune partition crypto. ça je n’ai pas essayer.

On peut, mais il faut faire attention à d’abord réduire la taille du volume chiffré (et de son contenu avant, etc.) avec cryptsetup.

[moondump]

Hello tous, merci pour votre participation.

@PascalHambourg

Tu as dû faire une erreur dans les tailles passées à pvresize et parted. Peut-être à cause de l’interprétation différente des préfixes multiplicateurs : « G » signifie gibi (giga binaire, 1024^3) pour pvresize et les autre commandes LVM, et giga (décimal, 1000^3, un peu plus petit) pour parted (pour qui gibi s’écrit « Gi »).

Je suis loin d’être à l’abri d’une erreur, mais ce n’est sans doute pas un problème d’unité vu l’énormité de la différence. J’ai d’ailleurs le même problème sur la station sur laquelle je travaillais au début du fil. Là, j’ai testé la manip sur un portable, c’était moins risqué.
Il faudrait que je fasse un essai à blanc pour voir d’où vient le problème. Mais bon, le temps, toujours le temps si précieux !

@PascalHambourg

Au mieux, la perte des données située au-delà de la nouvelle taille de la partition. Au pire, la perte de tous les volumes logiques ayant des données situées au-delà de la nouvelle taille.

Alors, existe-t-il une commande pour rassembler toutes les données au début de la partition ? Au temps béni du MsDOS, il existait « Defrag »…

[moondump]

Merci également à toi, Zargos.
Ta procédure va m’être fort utile !

[PascalHambourg]

@moondump

existe-t-il une commande pour rassembler toutes les données au début de la partition ?

LVM a la commande pvmove pour déplacer les données des volumes logiques d’un volume physique à un autre ou à l’intérieur d’un même volume physique. Je ne me souviens jamais de la syntaxe pour forcer le déplacement au début et je dois regarder la page de man, parfois c’est capricieux et il faut spécifier des plages d’extents.

[moondump]

OK, merci pour la piste… À creuser donc pour plus tard.

[Zargos]

@PascalHambourg

Que je sache, gpart ne sert pas à ça. Tu veux dire gdisk ?

Zut, oui gdisk pas gpart

@PascalHambourg

Si ça marchait si bien, Gparted ne devrait pas accepter de réduire un PV LVM en-dessous de la taille utilisée.

Oui c’est vrai, mais comme j’utilise le Live CD Gparted plutot que le CLI gparted, je ne suis pas sur. Du coup, deux précautions valent mieux qu’une.

@PascalHambourg

On peut, mais il faut faire attention à d’abord réduire la taille du volume chiffré (et de son contenu avant, etc.) avec cryptsetup.

C’est bon à savoir, vu que je vais surement avoir à réaliser l’opération dans un futur proche.

[PascalHambourg]

@Zargos

j’utilise le Live CD Gparted plutot que le CLI gparted

Gparted est un programme graphique, il n’a pas de CLI. Si tu parles de parted, c’est un programme complètement indépendant dont le seul point commun est d’utiliser la bibliothèque libparted et ses abstractions bizarres (drapeaux pour représenter les types) pour gérer les partitions.

@PascalHambourg

il faut faire attention à d’abord réduire la taille du volume chiffré (et de son contenu avant, etc.) avec cryptsetup.

Ou bien fermer le volume chiffré (après avoir réduit son contenu) avant de réduire son conteneur. A l’ouverture suivante, il prendra la nouvelle taille. En fait l’en-tête LUKS ne contient pas la taille du volume, elle est déterminée automatiquement à partir de la taille du conteneur.