Redimentionnement de partitions avec LVM

Support Debian
,
Tags: #<Tag:0x00007f509fb2c220> #<Tag:0x00007f509fb2c130>
#1

Salut la compagnie,

j’ai un blème, ma partition racine est saturée, jugez plutôt:

df

Sys. de fichiers            blocs de 1K   Utilisé Disponible Uti% Monté sur
udev                            4000728         0    4000728   0% /dev
tmpfs                            804736     10084     794652   2% /run
/dev/mapper/debian--vg-root    28703652  26520264     702276  98% /
tmpfs                           4023664     69704    3953960   2% /dev/shm
tmpfs                              5120         4       5116   1% /run/lock
tmpfs                           4023664         0    4023664   0% /sys/fs/cgroup
/dev/nvme0n1p2                   241965    114545     114928  50% /boot
/dev/nvme0n1p1                   523248      5220     518028   1% /boot/efi
/dev/mapper/debian--vg-home   207353644 135912220   60838724  70% /home
tmpfs                            804732        16     804716   1% /run/user/1000

Je désires prendre 5 Go sur la partition /home (ce qui je pense, devrait être suffisant).
Vous l’aurez deviné, je ne veux pas faire de conneries, y a-t’il une âme
charitable pour me guider?

merci par avance.

Quelques infos

pvdisplay

 --- Physical volume ---
 PV Name               /dev/nvme0n1p3
 VG Name               debian-vg
 PV Size               <237,74 GiB / not usable 0   
 Allocatable           yes (but full)
 PE Size               4,00 MiB
 Total PE              60860
 Free PE               0
 Allocated PE          60860
 PV UUID               eyxGzL-UbC4-4MGN-gZXh-DD2L-mYlw-4ZGj3M

lvdisplay

 --- Logical volume ---
 LV Path                /dev/debian-vg/root
 LV Name                root
 VG Name                debian-vg
 LV UUID                jX5Zou-V1MD-lhCH-MK1d-6IZm-QYRV-yDRU4Q
 LV Write Access        read/write
 LV Creation host, time debian, 2019-01-25 19:44:30 +0100
 LV Status              available
 # open                 1
 LV Size                <27,94 GiB
 Current LE             7152
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:0
  
 --- Logical volume ---
 LV Path                /dev/debian-vg/swap_1
 LV Name                swap_1
 VG Name                debian-vg
 LV UUID                4xZJGK-TpRv-CrOt-uhD1-6Bny-X2ZH-jmdxjE
 LV Write Access        read/write
 LV Creation host, time debian, 2019-01-25 19:44:30 +0100
 LV Status              available
 # open                 2
 LV Size                <7,88 GiB
 Current LE             2017
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:1
  
 --- Logical volume ---
 LV Path                /dev/debian-vg/home
 LV Name                home
 VG Name                debian-vg
 LV UUID                eVIa0r-qWy5-G3ch-THPm-6Og2-WOqO-ubFTBu
 LV Write Access        read/write
 LV Creation host, time debian, 2019-01-25 19:44:30 +0100
 LV Status              available
 # open                 1
 LV Size                <201,92 GiB
 Current LE             51691
 Segments               1
 Allocation             inherit
 Read ahead sectors     auto
 - currently set to     256
 Block device           254:2

ps: j’ai cru comprendre que ça pouvait se faire à chaud, sinon je peux toujours redémarrer sur une live-usb

#3

Avant de redimensionner, n’y a-t-il pas de nettoyage à faire dans le volume racine avant d’envisager de l’agrandir ?

Tu ne précises pas les types de systèmes de fichiers de / et /home. Je vais supposer ext4.

Fermer toutes les sessions d’utilisateur normal pour libérer /home.
Ouvrir une session root directement sans passer par une session utilisateur (donc pas via su ou sudo). Dans une console virtuelle tty1-6 ou en mode recovery si le gestionnaire de connexion graphique n’autorise pas d’ouvrir une session root.
Démonter /home.
Exécuter fsck -f sur le volume logique home.
Réduire le système de fichiers du volume logique home avec resize2fs si ext4.
Réduire le volume logique home à une taille supérieure ou égale (en aucun cas inférieure) à celle du système de fichiers avec lvreduce. Alternativement, on peut utiliser l’option --resizefs de lvreduce pour redimensionner le système de fichiers en même temps que le volume logique.
Remonter /home.
Agrandir le volume logique root avec lvextend.
Agrandir le système de fichiers du volume logique root avec resize2fs si ext4. Alternativement, on peut utiliser l’option --resizefs de lvextend pour redimensionner le système de fichiers en même temps que le volume logique.

#4

Merci de ton aide Pascal,

j’ai fais le ménage comme il se doit, cache, désinstallation de logiciels inusités, etc …
Effectivement j’ai omis de préciser le système de fichiers, il s’agit bien de ext4.

Bon, passons aux choses sérieuses, avec tes instructions et consultation des man, voici ce que je compte faire, si tu vois une bêtise, n’hésites pas, j’attendrais un peut avant de me lancer.
Je ne vais pas utiliser resize2fs mais l’option --resizefs comme tu me l’indiques.

1- J’ouvre une session root, je passerais directement par le mode recovery pour plus de sureté.

2- Démontage de /home:

umount /dev/mapper/debian--vg-home

3-

fsck -f /dev/mapper/debian--vg-home

, je ne trouve pas l’option -f dans le man, à quoi sert-elle?

4-

lvreduce --resizefs -L -5G /dev/mapper/debian--vg-home

, la syntaxe te parait-elle correcte?

5- Remontage du /home

mount /dev/mapper/debian--vg-home

6-

lvextend  --resizefs -L +5G /dev/mapper/debian--vg-root

, même question qu’au point 4.

Dernière question, le point 5 est-il nécessaire, vu que je rebooterais normalement ensuite?

Edit: modifs commandes 4 et 6

#5

Il y a plus court (idem pour le remontage) :

umount /home

C’est une option de e2fsck qui est appelé par fsck pour un système de fichiers ext4. Elle force la vérification même si le système de fichiers semble propre.

D’après la page de manuel, toutes les options doivent figurer avant le volume logique.

Oui car un échec du remontage signalerait immédiatement que quelque chose s’est mal passé lors de la réduction du volume home, et il ne faudrait surtout pas agrandir le volume root au risque de causer des dommages irréversibles. Je n’ai jamais utilisé l’option --resizefs, je ne connais pas sa fiabilité.

Par précaution tu pourrais faire une cartographie du volume logique home avec lvdisplay --maps avant de le réduire. Ainsi tu pourras l’agrandir dans sa configuration initiale si besoin.

Autre chose : tu pourrais réduire le volume home de plus que tu ne vas agrandir le volume root. Ainsi cela laissera de l’espace libre dans le groupe de volume pour facilement agrandir n’importe lequel des volumes logiques. C’est d’ailleurs ce qu’il aurait fallu faire lors du partitionnement, avec au moins 30% d’espace libre.

#6

Merci d’être à l’écoute Pascal, je t’offre un verre, malheureusement virtuel, mais le cœur y ait ;-).

  • ok pour le montage et remontage, je m’en doutais, quoique j’avais un doute, j’ai préféré un « truc » plus générique.

  • Pour fsck, merci de l’info, biz que ça ne soit pas dans le man, comment avoir ce genre d’info? (bon, c’est pas vraiment important ici, je te fais confiance, c’est pour savoir).

  • Vu pour les options, j’avais corrigé (l’Edit), par contre j’ai un doute sur l’espace entre -L et la quantité ajoutée.

*Pour le point 5, et Autre chose, j’ai compris ton doute, ces deux points me semble liés, pour plus de sécurité, je vais faire ( enfin quand cette discussion sera close :wink: ) un -6G suivi d’un +5G, accompagné d’un remontage et d’un lvdisplay --map et si je dectectes un truc qui cloche, je te ferais signe.

A la tienne Pascal!

ps: j’suis pas à la pièce! J’attends pas ce soir, y tiennent encore mes 98% ;-). Bonne soirée!

#7

C’est dans la page de manuel de fsck :

En réalité fsck n’est qu’une interface commune à toute une variété de vérificateurs de systèmes de fichiers (fsck.type) disponibles sous Linux. (…)
Veuillez consulter les pages de manuels des vérificateurs spécifiques à un système de fichiers pour de plus amples précisions.

Comme le type est ext4, il faut regarder dans la page de manuel de fsck.ext4 qui est un alias de e2fsck.

Non, il n’y a aucun rapport entre la vérification après réduction et la provision d’espace libre.

Une provision de 1 Gio d’espace libre sur 237 Gio, ça ne va pas chercher loin…

La cartographie doit être faite avant la réduction pour pouvoir revenir en arrière. Après, ça ne sert à rien.

#8

Toujours là, cool,

  • mon man fsck est en anglais, mais quand bien même, là, la traduction pour moi c’est du chinois, j’ai appris (humm…) quelque chose ;-).

  • fsck: Oui, je me suis mal exprimé, j’avais compris que l’option --resizefs ne t’était pas familière et que par conséquent tu me conseillais que vérifier par la suite si tout c’était passé normalement (à savoir laisser du gras pour la suite des opérations, ce qu’aurait fait resize2fs). C’est ça?

  • « 6Go et 5 Go »: Ouais, ok, mais 1Gio ou 10Gio, je suis bien tes recommandations là? (séquence vieux con: j’ai connu le temps où même un Mo ont savait pas ce que c’était :wink: ). De toute façon, le truc c’est que quand tu m’auras bien « briffé », je pourrais à loisir recommencer la manip et la diffuser.

  • Oui, pour lvdisplay --map, là encore c’est de ma faute, j’avais bien compris qu’il fallait le faire avant (c’est pas une « action » mais une « information »), je me suis mal exprimé, j’ai voulu tout mettre dans la même phrase.

Tu penses que je peux me lancer?

#9

Non, pas du tout.
fsck est requis par resize2fs avant une réduction. Peut-être que l’option --resizefs le fait automatiquement, je n’en sais rien.
Pas besoin de fsck après pour vérifier si la réduction s’est bien passée, il suffit de monter le système de fichiers.
Je ne vois pas de quel « gras » tu parles.

Si tu as besoin d’ajouter 5 Go maintenant, tu n’iras pas loin avec 1 Go de provision.

#10

Le « gras » dont je parle, c’est la partie libérée sur /home, mise de coté par resize2fs (si j’avais utilisé la commande) et destinée à /root,. Mais il est possible que mon vocabulaire ne soit par adéquat, ou pire que je sois à coté de la plaque ; visiblement c’est ce que tu penses, auquel cas, c’est bien que tu me corriges. Même si je fais ce que je peux pour comprendre ;-).

Concernant le 1Go de provision qui te parais dérisoire, si je suis capable, grâce à toi, de transférer 5Go d’espace libre d’une partition à l’autre, je pourrais le faire pour 100Go si le besoin s’en fait sentir. Donc, t’inquiètes, je gère mon espace ;-).

Ce que j’ai compris, c’est qu’il y avait deux manip à faire (là encore dis moi si je me trompe) : créer un espace libre (ce que resize2fest sensé faire à un niveau supérieur, les provisions dont tu parles?), puis « expliquer » au système virtuel (peut-être pas le bon vocabulaire) par deux commandes : tu récupère l’espace libéré voulu , tu l’enlève de /home et tu le file à /root.

Bon , visiblement, y’a plein de choses que je ne comprends pas (c’est cool pour moi, j’ai plein de choses à appendre), merci encore de ta patience.

#11

en fait il n’y a pas besoinde demonter les partitions.
LVM permet les redimensionnements à chaud.
Donc lvreduce pour /home
puis lvextend pour /
puis resize2fs sur les deux pour appliquer les redimensionnements
c’est tout

#12

Si.

Mais ext4 ne supporte pas la réduction à chaud.

Et une belle erreur se produira avec le volume home, car le système de fichiers est tronqué donc irréversiblement endommagé.
Qu’on puisse le faire à chaud ou pas, on doit toujours réduire le contenu (système de fichiers ici) avant le contenant (volume logique ici).

#13

resize2fs ne libère rien du tout, cela ne fait que réduire la taille du système de fichiers (indispensable pour que ce dernier ne soit pas tronqué lors de la réduction de son conteneur). C’est lvreduce qui, en réduisant un volume logique, libère de l’espace qui peut ensuite être alloué à un autre volume logique.

Mais il faudra à nouveau passer par démarrage en mode recovery, démontage du volume à réduire, réduction de son système de fichiers… C’est fastidieux et non dénué de risque, typiquement d’oublier de réduire le système de fichiers avec des conséquences potentiellement catastrophiques. Alors que si tu as laissé suffisamment d’espace libre, il suffira d’agrandir le volume cible et son système de fichiers, à chaud, sans rien démonter.

Non. Voir plus haut.

Non. Il n’y a pas de récupération d’espace libéré. Il y a réduction d’un volume, ce qui libère de l’espace, et agrandissement d’un autre, ce qui consomme de l’espace libre.
Ce n’est pourtant pas compliqué :
on réduit le contenu à la future taille du contenant pour qu’il ne soit pas tronqué (resize2fs ou --resizefs)
on réduit le contenant (lvreduce)
on agrandit le contenant (lvextend)
on agrandit le contenu à la nouvelle taille du contenant (resize2fs ou --resizefs)

1 J'aime
#14

Ok, c’est bon, j’ai pigé le rôle de chacun, Lv c’est la boite, le système de fichier (ici ext4) c’est les cerises, si je ne veux pas en faire de la confiture, il faut d’abord que je réduise la quantité de fruits avant de réduire la boite. C’est logique (sans jeu de mot).

Oui, je comprends là aussi ce que tu veux dire, mais je n’ai pas l’intention de faire ça tout les quatre matins. Et j’ai appris beaucoup avec cette discussion, je ne suis pas prêt d’oublier ;-).
1- S’occuper d’abord du contenu, (le système de fichier) avec resize2fs, s’assurer qu’il soit au moins inférieur ou égal à la future taille de la boite (lv).
2- Réduire la boite sans faire de la confiture avec lvreduce.

Note: l’option --resizefs de lvreduce s’occupe du point 1.
C’est bon?
Merci encore de ta patience.

ps: et pour l’agrandissement, c’est l’inverse, on fini avec resize2fs, pour adapter la quantité de cerise à la boite plus grande.

#15

Je récapitule:

1- J’ouvre une session root, je passerais directement par le mode recovery pour plus de sûreté.

2- Démontage de /home:

umount /dev/mapper/debian--vg-home

3-

fsck -f /dev/mapper/debian--vg-home

4-

lvreduce --resizefs -L -10G /dev/mapper/debian--vg-home

, je suis ton conseil, par sécurité, 5Go de coté.

5- Remontage du /home

mount /dev/mapper/debian--vg-home

6-

lvextend  --resizefs -L +5G /dev/mapper/debian--vg-root
#16

Oui, en principe, ainsi que du fsck, et ça devrait être plus sûr que la réduction séparée du système de fichiers puisque ça calcule automatiquement la bonne taille. Mais je n’ai jamais testé.

Ça me semble correct. fsck ne devrait pas être nécessaire avec l’option --resizefs.

#17

Ok, merci encore de ta patience, je suis conscient que ça n’a pas été facile ;-).

#18

Voilà, tout semble s’être déroulé sans accro, je n’ai pas utilisé fsck:

df -H

Sys. de fichiers            Taille Utilisé Dispo Uti% Monté sur
udev                          4,1G       0  4,1G   0% /dev
tmpfs                         825M     10M  815M   2% /run
/dev/mapper/debian--vg-root    35G     28G  5,9G  83% /
tmpfs                         4,2G     47M  4,1G   2% /dev/shm
tmpfs                         5,3M    4,1k  5,3M   1% /run/lock
tmpfs                         4,2G       0  4,2G   0% /sys/fs/cgroup
/dev/nvme0n1p2                248M    118M  118M  50% /boot
/dev/nvme0n1p1                536M    5,4M  531M   1% /boot/efi
/dev/mapper/debian--vg-home   202G    140G   53G  73% /home
tmpfs                         825M     17k  825M   1% /run/user/1000
#19

Bonjour,
Savez-vous pourquoi il faut être en root sans passer par su ? Et comment je peux faire ca en sachant que je suis sur une VM debian.

#20

S’il te plait ouvre ton propre fil de discussion, tu peux librement créer un lien vers ce fil de support au besoin.

#21