Estou executando o Proxmox 8.2.2. Recentemente meu lvg ficou corrompido ("o grupo de volumes pve não tem espaço livre suficiente!")
Primeiro, tentei reparar o vg:
$ sudo lvconvert --repair pve/data
Volume group "pve" has insufficient free space (2017 extents): 2077 required.
Então conectei um disco extra e adicionei-o ao grupo:
$ sudo pvcreate /dev/sdj
$ sudo vgextend pve /dev/sdj
e executei novamente o reparo:
$ sudo lvconvert --repair pve/data
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
WARNING: Sum of all thin volume sizes (<884.02 GiB) exceeds the size of thin pools (<794.79 GiB).
WARNING: You have not turned on protection against thin pools running out of space.
WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
WARNING: LV pve/data_meta2 holds a backup of the unrepaired metadata. Use lvremove when no longer required.
WARNING: New metadata LV pve/data_tmeta might use different PVs. Move it with pvmove if required.
Agora, meus dados estão acessíveis. Eu apaguei algumas coisas que não preciso. Aqui está o que eu quero fazer:
Evite que isso aconteça novamente, compreendendo os avisos acima em relação aos thin pools e estabelecendo limites.
Reduza a extensão do volume lógico para que eu não precise do disco físico extra que acabei de conectar.
Remova o disco físico sem danificar ou arriscar nada no lv.
Estou fora do meu alcance aqui - eu realmente apreciaria qualquer insight ou links para documentação para que eu possa entender como me meti nessa confusão, como posso impor limites para não entrar nisso novamente e como obter voltei a um estado em que o lvg não contém a nova unidade.
EDITAR:
$ sudo pvdisplay
--- Physical volume ---
PV Name /dev/sdk3
VG Name pve
PV Size 931.01 GiB / not usable 4.69 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 238338
Free PE 2017
Allocated PE 236321
PV UUID Msq2HF-K0f1-5spf-hWis-irni-vrLM-fiyq1N
--- Physical volume ---
PV Name /dev/sdj
VG Name pve
PV Size <1.82 TiB / not usable <1.09 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476932
Free PE 474855
Allocated PE 2077
PV UUID Jl1Jkd-4PJs-uAu9-bOUb-2yEQ-dnFb-YS5RVf
$ sudo vgdisplay
--- Volume group ---
VG Name pve
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 746
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 12
Open LV 5
Max PV 0
Cur PV 2
Act PV 2
VG Size <2.73 TiB
PE Size 4.00 MiB
Total PE 715270
Alloc PE / Size 238398 / 931.24 GiB
Free PE / Size 476872 / <1.82 TiB
VG UUID cmDgdu-22V6-Tx4j-pwNG-42ZZ-vRiG-SA850C
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
data pve twi-aotz-- <794.79g 61.00 3.20
data_meta0 pve -wi-a----- 8.11g
data_meta1 pve -wi-a----- 8.11g
root pve -wi-ao---- 96.00g
swap pve -wi-ao---- 8.00g
vm-100-disk-0 pve Vwi-aotz-- 32.00g data 20.35
vm-100-disk-1 pve Vwi-aotz-- 4.00m data 14.06
vm-102-disk-0 pve Vwi-aotz-- 10.00g data 35.51
vm-104-disk-0 pve Vwi-a-tz-- 8.00g data 57.03
vm-110-disk-0 pve Vwi-a-tz-- 4.00m data 14.06
vm-110-disk-1 pve Vwi-a-tz-- 650.00g data 72.34
vm-110-disk-2 pve Vwi-a-tz-- 4.00m data 1.56
$ sudo pvdisplay -m
--- Physical volume ---
PV Name /dev/sdk3
VG Name pve
PV Size 931.01 GiB / not usable 4.69 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 238338
Free PE 2017
Allocated PE 236321
PV UUID Msq2HF-K0f1-5spf-hWis-irni-vrLM-fiyq1N
--- Physical Segments ---
Physical extent 0 to 2047:
Logical volume /dev/pve/swap
Logical extents 0 to 2047
Physical extent 2048 to 26623:
Logical volume /dev/pve/root
Logical extents 0 to 24575
Physical extent 26624 to 230089:
Logical volume /dev/pve/data_tdata
Logical extents 0 to 203465
Physical extent 230090 to 232166:
Logical volume /dev/pve/data_meta0
Logical extents 0 to 2076
Physical extent 232167 to 234243:
Logical volume /dev/pve/data_meta1
Logical extents 0 to 2076
Physical extent 234244 to 236320:
Logical volume /dev/pve/data_tmeta
Logical extents 0 to 2076
Physical extent 236321 to 238337:
FREE
--- Physical volume ---
PV Name /dev/sdj
VG Name pve
PV Size <1.82 TiB / not usable <1.09 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 476932
Free PE 474855
Allocated PE 2077
PV UUID Jl1Jkd-4PJs-uAu9-bOUb-2yEQ-dnFb-YS5RVf
--- Physical Segments ---
Physical extent 0 to 2076:
FREE
Physical extent 2077 to 4153:
Logical volume /dev/pve/lvol1_pmspare
Logical extents 0 to 2076
Physical extent 4154 to 476931:
FREE
Isso não parece "corrupto", mas apenas que o tamanho mapeado dos volumes finos atingiu o tamanho do VG
Não sei o quanto você sabe sobre thin pool/provisionamento, mas essencialmente ele adiciona outra "camada" no topo do VG para que você possa criar LVs com um tamanho total maior que o VG . Os LVs (volumes finos, neste caso) "obteriam" blocos do pool fino à medida que fossem gravados com dados (ou seja, teriam seus blocos mapeados para os blocos do pool fino).
Com o passar do tempo, embora o que quer que use os volumes finos possa ter excluído arquivos indesejados nos sistemas de arquivos que residem nos volumes, isso não significa que os blocos "obtidos" para esses arquivos indesejados sejam "devolvidos" ao pool fino. Portanto, mesmo que o tamanho total ocupado pelos arquivos que ainda existem seja menor que o VG, não será possível obter mais blocos do thin pool para criação de novos arquivos nos thin volumes.
Para "recuperar" esses blocos "usados, mas não utilizados" para o thin pool, você precisará "descartar" os blocos mapeados correspondentes nos volumes thin. Se os volumes finos forem usados como discos virtuais em suas VMs, você deverá permitir o descarte na configuração do disco em cada VM e executar
fstrim
adequadamente na VM (assumindo que o sistema operacional convidado seja Linux). Para volumes que são usados diretamente pelo host proxmox (ou seja, formatados diretamente e montados lá), obviamente você deve executarfstrim
no proxmox. (Observe quefstrim
trabalhe através de pontos de montagem, portanto, não esperefstrim -a
ter efeito em partições/volumes finos não montados.)Obviamente, a maneira de automatizar tal ação seria habilitar
fstrim.timer
(ou qualquer coisa equivalente em uma distribuição não-systemd) ou montar o sistema de arquivos com adiscard
opção. (Se o sistema operacional não for Linux, certifique-se de que "TRIM" esteja "ativado" de qualquer maneira equivalente.)E eu acho que contanto que o espaço usado (que você pode tentar reduzir descartando) do thin pool (que é o espaço total usado dos volumes finos) seja menor que o tamanho atual do VG menos o tamanho do novo PV (
sdj
),you should be able to get myself back to a state where the lvg doesn't contain the new drive
usandovgreduce
. (Você pode precisar reduzir o pool fino manualmente primeiro. Eu realmente não sei o que exatamente aconteceria quando você tivesselvconvert --repair
um pool fino "cheio". Talvez ele o estendesse automaticamente. De qualquer forma, deve ser seguro apenas tentar executarvgreduce
primeiro e ver.)Você pode usar
lvs
para descobrir o uso atual (Data%
) do thin pool.PS, talvez você nunca tenha desejado thin pool/provisionamento, mas essa era apenas a abordagem padrão do proxmox; Não tenho ideia se existe uma maneira simples de mover os volumes finos para fora do pool fino, ou seja, torná-los "provisionados de maneira espessa" e, ao mesmo tempo, manter seus dados intactos.