Как уменьшить размер группы томов в 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

Итак, у меня есть VG с 65 ГБ свободного места. Но когда я хочу сжать эту группу томов примерно на 50 Гбайт:

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

Итак, сообщение об ошибке:

cannot resize to 63231 extents as later ones are allocated.

Q: Как я могу дефрагментировать vg_root, чтобы удалить ненужную часть?

ps: я уже узнал, что мне нужно только изменить размер PV, чтобы изменить размер VG, или есть какие-то лучшие команды для изменения размера VG (например: что я могу сделать, если бы я использовал несколько VG на PV? ... )?

Ответы:


31

Вы можете использовать pvmoveдля перемещения этих экстентов в начало устройства или другого устройства:

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

Затем pvmoveвыбирает, куда перемещать экстенты, или вы можете указать, куда их перемещать.

Посмотрите, pvs -v --segments /dev/deviceчтобы увидеть, какие экстенты в настоящее время выделены.


1
Для меня проблема заключалась в том, что он перенес PE в другие места. Пришлось указать пункт назначения например:sudo pvmove --alloc anywhere /dev/sdX2:60000-76182 /dev/sdX2:3000-19182
akostadinov

29

Это шаги, необходимые для изменения размера раздела LVM или LVM2:

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

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

Последняя команда pvresize, может привести к ошибке

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

Вы должны переставить нераспределенное пространство в конце LVM. Это означает, что после раздела root и swap_1. Вы можете увидеть текущее расположение пространства с помощью этой команды

pvs -v --segments /dev/sda5

pvs покажет вывод, как это

/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

Теперь используйте pvmoveдля удаления внешней фрагментации:

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

Теперь давайте посмотрим, удалось ли перенести том подкачки.

pvs -v --segments /dev/sda5

должен показать новый порядок объемов:

/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

После этого используйте GParted и измените размер LVM до максимально используемой площади. Остальное будет в нераспределенном пространстве.


Это довольно полный ответ, хотя было бы полезно, если бы он включал шаг 0 для изменения размера файловой системы, например, resize2fs. Я не думаю, что это должно быть подробно, но было бы полезно иметь что-то, что подтолкнуло бы будущих зрителей
Джастин

Вначале у меня было свободное место, вызов pvmove без пункта назначения не переместил его в начало. То, что сработало, было pvmove --alloc anywhere /dev/sda5:yyyy-end 0-newendс "newend", рассчитанным как end - yyyy. Однако я не уверен, работает ли это, если свободное пространство в начале меньше, чем диапазон, который нужно переместить. Также я думаю, что в ваших выводах pvs есть опечатка, я думаю, вы имели в виду /dev/sda5:0-xxxвместо /dev/sda:0-xxx.
pcworld

2
@Justin --resizefsПараметр lvresizeуже заботится об изменении размера базовой файловой системы.
pcworld

@pcworld просто прочитал справочную страницу и, кажется, ты прав
Джастин

Отличный ответ - но не могли бы вы уточнить последний шаг? Я предполагаю, что «изменить размер LVM» означает «изменить размер физического тома?» Есть ли способ сделать это без GParted, в командной строке, для систем, которые не имеют GUI?
Кевин Кин

1

В этом старом посте рассказывается об уменьшении, поэтому вы можете использовать новое пространство для чего-то другого. Вам нужно будет изменить его размер до данных, однако, прежде. Это должно охватывать и другие ошибки, которые вы получаете. Поскольку это старше, прочитайте сначала:


0

я использую этот метод, не уверен, что это лучший, но работает для меня

используйте его с осторожностью, а не сисадмин

рассчитать разницу, которая вызывает проблему

324% 4 = 0 без проблем

но

324% 32 = 10,125

это проблема, поэтому она не подходит

я думаю, что это называется "получить реальное число"

lvmdiskscan

перечислить задействованные разделы

тогда

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

я должен добавить 4M к работе, я думаю, что это связано со старым размером PE

Ну наконец то

vgchange -s 32M **

0

Предыдущие ответы помогли мне решить эту проблему, но мне нужно было ее автоматизировать и поэтому написал 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

Это вызывает pvmove столько раз, сколько необходимо для дефрагментации PV, а затем изменяет его размер до минимально возможного размера (который немного больше используемого размера из-за метаданных).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.