Perguntas[lvm](unix)

No Ubuntu, montei um arquivo .img de disco bruto como um dispositivo de loop que contém um LVM criptografado por LUKS com uma instalação do Ubuntu nele.

É montado assim: (a saída é delsblk -o NAME,PKNAME,KNAME,FSTYPE,SIZE /dev/loop0

NAME                      PKNAME KNAME FSTYPE        SIZE
loop0                            loop0               240G
├─loop0p1                 loop0  dm-11 ext4          487M
├─loop0p2                 loop0  dm-12                 1K
└─loop0p5                 loop0  dm-13 crypto_LUKS 239.5G
  └─cloneluks             dm-13  dm-14 LVM2_member 239.5G
    ├─ubuntuclone-lv_swap dm-14  dm-15                 8G
    └─ubuntuclone-lv_root dm-14  dm-16 ext4        231.5G

Existe algum comando que eu possa usar em um script para retornar o "dispositivo de bloco" raiz (não tenho certeza se esse é o termo correto) quando eu dou o nome do LV montado?

Eu esperava que isso lsblk -no pkname /dev/ubuntuclone/lv_rootfuncionasse, mas não gera nada - usar knameme dá dm-16.

Eu quero chegar a loop0.

Também vi esta resposta que sugeria que eu poderia usar "$(basename "$(readlink -f /dev/VG/LV)")", mas não consegui descobrir como usá-la:

 dev=/dev/ubuntuclone/lv_root ; echo "$(basename "$(readlink -f $dev)")"

saídas dm-16.

Não consigo descobrir como "passar" pelo contêiner crypto_LUKS.

É isso que estou procurando:

para entrada:

/dev/ubuntuclone/lv_rootouubuntuclone-lv_root

Gostaria de obter a saída:

/dev/loop0

Obrigado.

editar: Acho que usar lsblk --json | jqpode ser exatamente o que eu quero, mas estou tendo muita dificuldade em descobrir os encantamentos corretos para jq...

Adicionei um segundo NVMEno meu computador e estendi meu volume LVM criptografado. Usei os seguintes comandos para estendê-lo:

sudo pvcreate /dev/nvme0n1            << New disk
sudo vgextend castel-vg /dev/nvme0n1
sudo lvm lvextend -l +100%FREE /dev/castel-vg/root
sudo resize2fs -p /dev/mapper/castel--vg-root

A partição está bem estendida e tudo funciona bem, mas agora se eu olhar o lsblkresultado:

lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
nvme1n1                   259:0    0  3.6T  0 disk  
├─nvme1n1p1               259:1    0  512M  0 part  /boot/efi
├─nvme1n1p2               259:2    0  488M  0 part  /boot
└─nvme1n1p3               259:3    0  3.6T  0 part  
  └─nvme0n1p3_crypt       254:0    0  3.6T  0 crypt 
    ├─castel--vg-root     254:1    0  7.3T  0 lvm   /
    └─castel--vg-swap_1   254:2    0  976M  0 lvm   [SWAP]
nvme0n1                   259:4    0  3.6T  0 disk  
└─castel--vg-root         254:1    0  7.3T  0 lvm   /

As duas últimas linhas estão me dando uma dúvida de que a partição castel--vg-rootna unidade nvme0n1não está usando a camada de criptografia LUKS. Existe alguma maneira de confirmar ou não se a partição estendida está bem criptografada?

Atualizar:

Enquanto eu tentava desenhar isso, para ajudar a esclarecer minha pergunta (a ??parte), notei que também não está claro para mim onde está o crypt/LUKS. É nvme0n1p3_cryptuma partição ou um VolumeGroup?

Gostaria de desligar event_activationenquanto modifico uma unidade desmontada (as regras do udev são executadas vgchangequando uma alteração na unidade desmontada é detectada). A página do manual diz que "lvm.conf é carregado durante a fase de inicialização do lvm". Posso recarregar o lvm para forçar uma releitura do lvm.conf?

Se eu definir event_activationcomo 0 em lvm.conf e executar lvm dumpconfig, ele relata o novo valor, mas presumivelmente não age sobre ele. Se necessário, eu poderia simplesmente desligar o LVM (o sistema é reinicializado após modificar a unidade) - há uma maneira de fazer isso? Estranhamente, adicionar nolvmàs opções do kernel não parece afetar esse problema - vgchangeainda é executado quando a unidade é modificada.

Geralmente inicializo meu sistema a partir de um único SSD NVMe M.2 de 250G (PCIe 3.0 x4). Também tenho um SSD SATA de 240G e um HDD SATA de 640G e 7200rpm que atualmente uso para backup ad hoc . Este último será substituído por um backup remoto adequado, então tenho essas unidades livres.

Estou pensando em criar um volume lógico de 240 G usando LVM em uma configuração RAID1 para ter dois espelhos (ou seja, três imagens no total) do meu sistema.

Quero saber se isso será mais lento ou mais rápido do que minha configuração atual. Meu objetivo principal para isso é redundância, mas prefiro não degradar o desempenho. Posso considerar deixar o HDD fora da mistura se for provável que seja um problema.

Não sei nada específico sobre o cache/buffering dos drives de cabeça. Mas tenho 16 GB de RAM e, se for importante, usarei ext4 por enquanto.

Estou tentando aumentar o tamanho do meu pv/vg/lv depois de adicionar um novo gabinete de armazenamento e criei 2 novos volumes e anexei-os ao host. Embora o aumento de PV e VG tenha funcionado muito bem, parece que LV não vê nenhum espaço livre. Talvez alguém possa me indicar a direção certa por que isso não está funcionando?

O que foi feito até agora:

rescan-scsi-bus.sh -r

pvcreate /dev/mapper/mpathe
  Physical volume "/dev/mapper/mpathe" successfully created.
pvcreate /dev/mapper/mpathf
  Physical volume "/dev/mapper/mpathf" successfully created.
vgextend vgall /dev/mapper/mpathe
  Volume group "vgall" successfully extended
vgextend vgall /dev/mapper/mpathf
  Volume group "vgall" successfully extended

mas agora lvextend mostra isso:

lvextend -l +100%FREE /dev/vgall/lvol0
  Using stripesize of last segment 4.00 KiB
  Rounding size (152285551 extents) down to stripe boundary size for segment (152285548 extents)
  Size of logical volume vgall/lvol0 changed from 478.39 TiB (125408168 extents) to 478.51 TiB (125439052 extents).
  Logical volume vgall/lvol0 successfully resized.

o que basicamente não é nada, e as execuções subsequentes mostram:

lvextend -l +100%FREE  /dev/vgall/lvol0
  Using stripesize of last segment 4.00 KiB
  Rounding size (152285551 extents) down to stripe boundary size for segment (152285548 extents)
  Size of logical volume vgall/lvol0 unchanged from 478.51 TiB (125439052 extents).
  Command failed with status code 5.

Saída do display PV / LV / VG abaixo:

  --- Physical volume ---
  PV Name               /dev/mapper/mpatha
  VG Name               vgall
  PV Size               <119.60 TiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              31352042
  Free PE               0
  Allocated PE          31352042

  --- Physical volume ---
  PV Name               /dev/mapper/mpathb
  VG Name               vgall
  PV Size               <119.63 TiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              31359763
  Free PE               0
  Allocated PE          31359763

  --- Physical volume ---
  PV Name               /dev/mapper/mpathc
  VG Name               vgall
  PV Size               <119.60 TiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              31352042
  Free PE               0
  Allocated PE          31352042

  --- Physical volume ---
  PV Name               /dev/mapper/mpathd
  VG Name               vgall
  PV Size               <119.63 TiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              31359763
  Free PE               0
  Allocated PE          31359763

  --- Physical volume ---
  PV Name               /dev/mapper/mpathe
  VG Name               vgall
  PV Size               <51.27 TiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              13438976
  Free PE               13431255
  Allocated PE          7721

  --- Physical volume ---
  PV Name               /dev/mapper/mpathf
  VG Name               vgall
  PV Size               51.20 TiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              13422965
  Free PE               13415244
  Allocated PE          7721


  --- Volume group ---
  VG Name               vgall
  System ID
  Format                lvm2
  Metadata Areas        6
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                6
  Act PV                6
  VG Size               580.92 TiB
  PE Size               4.00 MiB
  Total PE              152285551
  Alloc PE / Size       125439052 / 478.51 TiB
  Free  PE / Size       26846499 / 102.41 TiB


  --- Logical volume ---
  LV Path                /dev/vgall/lvol0
  LV Name                lvol0
  VG Name                vgall
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                478.51 TiB
  Current LE             125439052
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:6



lvdisplay -m /dev/vgall/lvol0
  --- Logical volume ---
  LV Path                /dev/vgall/lvol0
  LV Name                lvol0
  VG Name                vgall
  LV UUID                MKcUYB-dAoJ-qJq1-hQEy-ArGl-c0bi-WKY0bU
  LV Write Access        read/write
  LV Creation host, time localhost.localdomain, 2023-10-04 20:00:04 +0200
  LV Status              available
  # open                 1
  LV Size                478.51 TiB
  Current LE             125439052
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:6

  --- Segments ---
  Logical extents 0 to 125408167:
    Type                striped
    Stripes             4
    Stripe size         4.00 KiB
    Stripe 0:
      Physical volume   /dev/mapper/mpathb
      Physical extents  0 to 31352041
    Stripe 1:
      Physical volume   /dev/mapper/mpathd
      Physical extents  0 to 31352041
    Stripe 2:
      Physical volume   /dev/mapper/mpatha
      Physical extents  0 to 31352041
    Stripe 3:
      Physical volume   /dev/mapper/mpathc
      Physical extents  0 to 31352041

  Logical extents 125408168 to 125439051:
    Type                striped
    Stripes             4
    Stripe size         4.00 KiB
    Stripe 0:
      Physical volume   /dev/mapper/mpathe
      Physical extents  0 to 7720
    Stripe 1:
      Physical volume   /dev/mapper/mpathf
      Physical extents  0 to 7720
    Stripe 2:
      Physical volume   /dev/mapper/mpathb
      Physical extents  31352042 to 31359762
    Stripe 3:
      Physical volume   /dev/mapper/mpathd
      Physical extents  31352042 to 31359762

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:

1. Evite que isso aconteça novamente, compreendendo os avisos acima em relação aos thin pools e estabelecendo limites.

2. Reduza a extensão do volume lógico para que eu não precise do disco físico extra que acabei de conectar.

3. 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

Estou configurando um sistema Linux em KVM (QEMU) para testar o efeito de adicionar um cache LVM de write-back em um disco rápido na frente de um volume lógico que reside em um conjunto de discos muito lentos (um RAID1 LV). Isso é modelado em uma configuração física real que não quero tocar até saber como ela pode lidar com o cache adicionado.

O problema é que no KVM todos os discos funcionam na mesma velocidade, portanto o cache raramente é utilizado e não vejo nenhum benefício de desempenho. Idealmente, quero que o espelho RAID1 tenha dificuldades com E/S, permitindo-me observar o volume do cache sendo preenchido durante as gravações e gradativamente gradativamente no conjunto de espelhos.

Existe uma maneira de acelerar artificialmente a velocidade de um disco no KVM/QEMU?

Atualmente estou usando o Debian 12 como host para este experimento, com a máquina KVM rodando Alpine Linux (e também testando com o Debian 12). A configuração do KVM inclui uma imagem qcow2 principal (o disco rápido) e imagens qcow2 adicionais (o espelho RAID lento).

Tendo 1 SSD de 500GB e 1 HD de 1TB, o SSD já faz parte do Volume Lógico, o HD é montado com fstab. Tudo funciona bem.

Porém, por curiosidade, se eu decidir estender a segunda unidade (/dev/sda1) para o Volume Lógico, ainda poderei decidir o que acontece em qual unidade e como?

Já pratiquei um pouco, então estou familiarizado com pvcreate e vgextend (máquinas virtuais), então essa parte está ok. Mas não consigo mover dados de uma unidade específica para outra, ambos no mesmo grupo de volumes.

Obrigado pela sua contribuição

Eu tenho um grupo de volumes LVM existente com um volume lógico de 10 TB montado como um sistema ext4 que está em uso ativamente.

É seguro executar o comando lvconvert --type cache --cachepool storage/lvmcache-data storage/dataenquanto o sistema de arquivos ext4 já está montado storage/data? (O storage/lvmcache-datafoi previamente configurado lvconvert --type cache-pool --cachemode writeback --poolmetadata storage/lvmcache-metadata storage/lvmcache-datacaso faça diferença.)

Eu diria que sim, é seguro adicionar cache dinamicamente ao volume online com sistema de arquivos montado, mas não consegui encontrar documentação de qualquer maneira.

então posso ver no lsblk que tenho um disco de 250G, mas quando executo pvresize /dev/sda3 não consigo ver o espaço livre para estender o grupo de volumes. Preciso modificar a tabela de partições no modo de usuário único, pois este é o sistema de arquivos raiz? Em um sistema semelhante, consegui executar pvresize, vgextend, lvresize e depois resize2fs