Por que existem dois valores diferentes para o tamanho de uma unidade e como reconciliá-los com o mapeador de dispositivos e o LVM?

Eu tenho uma unidade de 1 TB conectada via USB. Ele contém um volume físico LVM preenchendo o dispositivo inteiro (sem nenhuma tabela de partição). Quando tentei estender um volume lógico usando o PV inteiro, o mapeador de dispositivos começou a reclamar que a seção alocada pelo LVM no PV é maior que o dispositivo. A mensagem de erro do dispositivo-mapeador (como mostrado dmesg) relata um tamanho de 1953320367 [dm] setores:

device-mapper: table: 254:0: sdf too small for target: start=1821353984, len=132169728, dev_size=1953320367

Mas o LVM criou um PV com 238467 extensões físicas , que são 1953521664 [lvm] setores (com cerca de 100 MB a mais):

$ pvdisplay /dev/sdf
  --- Physical volume ---
  PV Name               /dev/sdf
  VG Name               apu-vg1
  PV Size               931.51 GiB / not usable 1.71 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              238467
  Free PE               100
  Allocated PE          238367
  PV UUID               LrKDDW-4dXz-kDgh-CK78-OWhY-4sCH-rKT0e4

Agora, se eu executar hdparm -gIno dispositivo, posso ver dois valores para o tamanho do dispositivo. Sob geometria , há o mesmo valor relatado pelo mapeador de dispositivo que o tamanho do dispositivo. Porém, nos setores endereçáveis pelo usuário do LBA48 , existe o valor 1953525168 [lba], que é menos de um PE maior que o tamanho combinado dos PEs do PV. Isso me faz pensar que esse é o valor que o LVM vê:

$ hdparm -Ig /dev/sdf

/dev/sdf:
 geometry      = 121588/255/63, sectors = 1953320367, start = 0

ATA device, with non-removable media
          Model Number:       ST1000LM024 HN-M101MBB                  
          Serial Number:      S2RUJ9BC702524      
          Firmware Revision:  2AR10001
          Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
          Used: unknown (minor revision code 0x0028) 
          Supported: 8 7 6 5 
          Likely used: 8
Configuration:
          Logical         max     current
          cylinders       16383   16383
          heads           16      16
          sectors/track   63      63
          --
          CHS current addressable sectors:   16514064
          LBA    user addressable sectors:  268435455
          LBA48  user addressable sectors: 1953525168
...

Agora às minhas perguntas:

Por que existem dois valores diferentes para o tamanho do dispositivo usado por diferentes partes do kernel?
E, como eu manejo / conserto essa situação para que o LVM não crie PVs maiores que o espaço que o mapeador de dispositivos está disposto / capaz de acessar?

— Feuermurmel
fonte

qual é o comando exato que você está executando quando estende? As cabeças LVM geralmente recebem 2 MB, aproximadamente o tamanho da sua discrepância.

— Bratchley

O tamanho menor relatado por hdparmé o maior número que é múltiplo de 255 * 63 setores e menor que o tamanho real. Essa restrição se deve ao formato de cilindro / cabeçote / setores da interface do BIOS de 30 anos. A interface mais recente do LBA48 pode informar o tamanho do seu disco muito bem. Não faço ideia por que o Linux usa o tamanho do CHS para qualquer coisa.

— Gilles 'SO- stop be evil'

Marquei os diferentes valores entre colchetes para consultá-los facilmente.

— Feuermurmel

@JoelDavis Estendi o VG usando uma planície vgextend <vg-name> /dev/sdf. O LVM faz exatamente o que eu espero. pvdisplaydiz ainda que 1,71 MiB são inutilizáveis, exatamente o tamanho da diferença entre [lvm] e [lba].

— Feuermurmel

@Feuermurmel, edite sua pergunta para fornecer informações adicionais - não use comentários.

— Guntbert 17/05

O principal problema aqui é o seu Free PEvalor. Observe como diz que apenas 100 extensões são gratuitas? Isso significa que você não poderá estendê-lo. Se você faz um vgscan, pvscan e depois um vgdisplay (também vgs), provavelmente verá que seu dispositivo já faz parte de um vg (e provavelmente lv (s) também), e é por isso que as extensões não são gratuitas.

Você poderia fornecer a saída de:

vgscan;pvscan;vgdisplay;vgs

você poderá obter 400 MB adicionais com base no tamanho de suas extensões e quantas são gratuitas.

— Khrystoph
fonte

Sim, esse PV já possui 238367 PE alocado para um LV. Essas 100 extensões são gratuitas porque reduzi o LV depois que o mapeador de dispositivos reclamou que o mapeamento solicitado pelo LVM estava fora do alcance. Meu problema é que o PV criado pelo LVM é realmente maior que o disco físico. Esse disco em questão não faz mais parte do sistema, portanto não posso fornecer a saída solicitada.

— Feuermurmel 17/09/2015