Comment réduire la taille du groupe de volumes dans LVM?
[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 puis-je défragmenter le vg_root afin que je puisse 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? ... )?
Vous pouvez utiliser pvmove pour déplacer ces extensions au début du périphérique ou d'un autre périphérique:
Sudo pvmove --alloc anywhere /dev/device:60000-76182
Ensuite, pvmove choisit où déplacer les extensions, ou vous pouvez spécifier où les déplacer.
Voir pvs -v --segments /dev/device pour voir les extensions actuellement allouées.
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
Utilisez maintenant pvmove pour 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é.
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:
Les réponses précédentes m'ont aidé à résoudre ce problème, mais j'avais besoin de l'automatiser et ainsi é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).
j'utilise cette méthode, je ne sais pas si c'est la meilleure mais ça marche pour moi
utilisez-le avec prudence et pas 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 **