Comment réduire la taille du groupe de volumes dans LVM?


30
[root@localhost ~] vgdisplay
  --- Volume group ---
  VG Name               vg_root
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  7
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               297,59 GiB
  PE Size               4,00 MiB
  Total PE              76182
  Alloc PE / Size       59392 / 232,00 GiB
  Free  PE / Size       16790 / 65,59 GiB
  VG UUID               XXXXXXXXXX

PV:

[root@localhost ~] pvdisplay

  --- Physical volume ---
  PV Name               /dev/mapper/udisks-luks-uuid-ASDFASDF
  VG Name               vg_root
  PV Size               297,59 GiB / not usable 2,00 MiB
  Allocatable           yes 
  PE Size               4,00 MiB
  Total PE              76182
  Free PE               16790
  Allocated PE          59392
  PV UUID               YYYYYYYYYYY

J'ai donc un VG avec 65 Go d'espace libre. Mais quand je veux réduire ce groupe de volumes d'environ ~ 50 Go:

pvresize -tv --setphysicalvolumesize 247G /dev/mapper/udisks-luks-uuid-ASDFASDF
  Test mode: Metadata will NOT be updated and volumes will not be (de)activated.
    Using physical volume(s) on command line
    Test mode: Skipping archiving of volume group.
    /dev/mapper/udisks-luks-uuid-ASDFASDF: Pretending size is 517996544 not 624087040 sectors.
    Resizing volume "/dev/mapper/udisks-luks-uuid-ASDFASDF" to 624087040 sectors.
    Resizing physical volume /dev/mapper/udisks-luks-uuid-ASDFASDF from 0 to 63231 extents.
  /dev/mapper/udisks-luks-uuid-ASDFASDF: cannot resize to 63231 extents as later ones are allocated.
  0 physical volume(s) resized / 1 physical volume(s) not resized
    Test mode: Wiping internal cache
    Wiping internal VG cache

Le message d'erreur est donc:

cannot resize to 63231 extents as later ones are allocated.

Q: Comment défragmenter vg_root pour pouvoir en supprimer la partie inutile?

ps: J'ai déjà découvert que je n'ai besoin que de redimensionner le PV pour redimensionner le VG, ou y a-t-il de meilleures commandes pour faire le redimensionnement du VG (ex: que puis-je faire si je souhaite plusieurs VG sur un PV? ... )?

Réponses:


31

Vous pouvez utiliser pvmovepour déplacer ces extensions au début de l'appareil ou d'un autre appareil:

sudo pvmove --alloc anywhere /dev/device:60000-76182

pvmoveChoisit ensuite où déplacer les extensions, ou vous pouvez spécifier où les déplacer.

Voir pvs -v --segments /dev/devicepour voir quelles extensions sont actuellement allouées.


1
Pour moi, le problème est qu'il a déplacé les PE vers d'autres endroits. Dû spécifier la destination, par exemple:sudo pvmove --alloc anywhere /dev/sdX2:60000-76182 /dev/sdX2:3000-19182
akostadinov

29

Voici les étapes requises pour redimensionner une partition LVM ou LVM2:

sudo lvresize --verbose --resizefs -L -150G /dev/ubuntu/root

sudo pvresize --setphysicalvolumesize {any size here} /dev/sda5

La dernière commande pvresize,, peut générer l'erreur

/dev/sda5: cannot resize to xxxxx extents as later ones are allocated.

Vous devez réorganiser l'espace non alloué à la fin du LVM. Cela signifie après la partition racine et swap_1. Vous pouvez voir l'agencement actuel de l'espace avec cette commande

pvs -v --segments /dev/sda5

pvs affichera une sortie comme celle-ci

/dev/sda5 ubuntu lvm2 a-- 698.04g 150g 0 xxx+1 root 0 linear /dev/sda:0-xxx
/dev/sda5 ubuntu lvm2 a-- 698.04g 150g xxx+1 iii 0 free
/dev/sda5 ubuntu lvm2 a-- 698.04g 150g yyyy jjj swap 0 linear /dev/sda5:yyyy-end

Maintenant, utilisez pvmovepour supprimer la fragmentation externe:

sudo pvmove --alloc anywhere /dev/sda5:yyyy-end

Voyons maintenant si le déplacement du volume d'échange a réussi.

pvs -v --segments /dev/sda5

devrait montrer le nouvel ordre des volumes:

/dev/sda5 ubuntu lvm2 a-- 698.04g 150g 0 xxx+1 root 0 linear /dev/sda:0-xxx
/dev/sda5 ubuntu lvm2 a-- 698.04g 150g xxx+1 iii swap 0 linear /dev/sda5:xxx+1-yyyy
/dev/sda5 ubuntu lvm2 a-- 698.04g 150g yyyy+1 end 0 free

Après cela, utilisez GParted et redimensionnez le LVM à la zone maximale utilisée. Le reste sera dans l'espace non alloué.


C'est une réponse assez complète - elle serait utile si elle incluait une étape 0 pour faire le redimensionnement du système de fichiers, par exemple resize2fs. Je ne pense pas que cela doive être détaillé, mais avoir juste quelque chose comme un coup de pouce aux futurs téléspectateurs serait utile
Justin

J'avais de l'espace libre au début, appeler pvmove sans destination ne l'a pas déplacé au début. Ce qui a fonctionné était pvmove --alloc anywhere /dev/sda5:yyyy-end 0-newendavec "newend" calculé comme fin - aaaa. Cependant, je ne sais pas si cela fonctionne si l'espace libre au début est plus petit que la plage à déplacer. Je pense aussi qu'il y a une faute de frappe dans vos sorties pvs, je pense que vous vouliez dire /dev/sda5:0-xxxau lieu de /dev/sda:0-xxx.
pcworld

2
@Justin Le --resizefsparamètre de lvresizeprend déjà en charge le redimensionnement du système de fichiers sous-jacent.
pcworld

@pcworld vient de lire la page de manuel et semble avoir raison
Justin

Excellente réponse - mais pouvez-vous élaborer sur la dernière étape? Je suppose que "redimensionner le LVM" signifie "redimensionner le volume physique?" Existe-t-il un moyen de le faire sans GParted, sur la ligne de commande, pour les systèmes qui n'ont pas d'interface graphique?
Kevin Keane

1

Cet article plus ancien couvre ce type de rétrécissement afin que vous puissiez utiliser le nouvel espace pour autre chose. Vous devrez cependant le redimensionner en fonction des données avant. Cela devrait couvrir cela et d'autres erreurs que vous obtenez également. Comme il est plus ancien, lisez d'abord:


0

j'utilise cette méthode, je ne sais pas si c'est la meilleure mais ça marche pour moi

utilisez-le avec prudence et non avec SysAdmin

calculer la différence qui cause le problème

324% 4 = 0 pas de problème

mais

324% 32 = 10,125

c'est le problème donc ça ne rentre pas

Je pense que ça s'appelle "obtenir un vrai numéro"

lvmdiskscan

pour répertorier les partitions impliquées

puis

pvresize /dev/*** --setphysicalvolumesize ***M

je dois ajouter 4M supplémentaires pour travailler, je pense que c'est lié à l'ancienne taille PE

enfin

vgchange -s 32M **

0

Les réponses précédentes m'ont aidé à résoudre ce problème, mais j'avais besoin de l'automatiser et c'est ce qu'a écrit pvshrink

# ./pvshrink /dev/vda2 
Moving 50 blocks from 714 to 664
  /dev/vda2: Moved: 4.00%
  /dev/vda2: Moved: 100.00%
50 of 50 (100.00%) done
Defragmentation complete.
Metadata size: 1048576 b
PE size: 4.0 MiB
Total size 1048576 b + 714 x 4194304 b = 2995781632 b (2.8 GiB)
    Wiping internal VG cache
    Wiping cache of LVM-capable devices
    Archiving volume group "fedora" metadata (seqno 15).
    /dev/vda2: Pretending size is 5851136 not 6287360 sectors.
    Resizing volume "/dev/vda2" to 5851136 sectors.
    Resizing physical volume /dev/vda2 from 0 to 714 extents.
    Updating physical volume "/dev/vda2"
    Creating volume group backup "/etc/lvm/backup/fedora" (seqno 16).
  Physical volume "/dev/vda2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Cela appelle pvmove pour vous autant de fois que nécessaire pour défragmenter le PV, puis le redimensionne à sa taille minimale possible (qui est légèrement supérieure à la taille utilisée en raison des métadonnées).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.