1.)
Da página do manual:
pvresize
will refuse to shrink PhysicalVolume if it has allocated extents after where its new end would be.
Você pode fazer isso apenas por teste & erro. Na verdade, pvresize
dirá a você parte disso:
/dev/dm-7: cannot resize to 17564 extents as 18620 are allocated.
Para determinar o tamanho exato, você precisa saber o tamanho do PE (por exemplo, 4MiB) e o 1º deslocamento do PE (por exemplo, 1MiB). E, claro, o número da última extensão alocada.
pvs -o pv_name,pe_start,vg_extent_size,seg_pe_ranges
Assim, o tamanho total poderia ser, por exemplo, 1MiB (1ª PE) + 18620 * 4MiB (tamanho PE).
2.)
Você precisa saber o tamanho do cabeçalho / deslocamento de dados do LUKS. Normalmente, isso é 4096 setores, ou seja, 2 MiB. Verifique com cryptsetup luksDump
, Payload offset
.
Portanto, o novo tamanho da sua partição é o deslocamento de Payload da LUKS, além do tamanho que você redimensionou para o próprio PV.
3.)
Sim e não. O LUKS não mantém o tamanho em seus metadados, portanto, se você for fechar o contêiner LUKS ou mesmo reinicializar, então sim, ele usará apenas o tamanho do próprio dispositivo de bloco.
Mas, para um redimensionamento on-line, você precisaria defini-lo com cryptsetup resize
, para o tamanho que você usou em pvresize
.
4.)
Às vezes, faço isso passando o dispositivo ofensivo no modo somente leitura para uma instância do qemu / KVM, executando algum sistema de recuperação do Linux. É difícil verificar o host (com, digamos, um dispositivo de loop somente leitura) porque o LVM não gosta de ver UUIDs de PV duplicados ou nomes de VG / LV. O LVM se recusará a ativar, caso o PV seja menor que o esperado.