Pourquoi existe-t-il deux valeurs différentes pour la taille d'un lecteur et comment les réconcilier avec Device-mapper et LVM?

J'ai un lecteur de 1 To connecté via USB. Il contient un volume physique LVM remplissant l'ensemble du périphérique (sans table de partition). Lorsque j'ai essayé d'étendre un volume logique en utilisant l'intégralité du PV, le mappeur de périphériques a commencé à se plaindre que la section allouée par LVM sur le PV est plus grande que le périphérique. Le message d'erreur du mappeur de périphériques (comme indiqué par dmesg) signale une taille de 1953320367 [dm] secteurs:

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

Mais LVM a créé un PV avec 238467 extensions physiques , soit 1953521664 [lvm] secteurs (soit environ 100 Mo de plus):

$ 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

Maintenant, si je cours hdparm -gIsur l'appareil, je peux voir deux valeurs pour la taille de l'appareil. Sous la géométrie , il y a la même valeur qui est rapportée par le mappeur de périphérique que la taille du périphérique. Mais sous les secteurs adressables par l'utilisateur LBA48 , il y a la valeur 1953525168 [lba], qui est inférieure de plus d'un PE à la taille des moissonneuses-batteuses des PE du PV. Cela me fait penser que c'est la valeur que voit LVM:

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

Passons maintenant à mes questions:

Pourquoi y a-t-il deux valeurs différentes pour la taille du périphérique utilisées par différentes parties du noyau?
Et, comment gérer / corriger cette situation afin que le LVM ne crée pas de PV plus grands que l'espace auquel le mappeur de périphériques souhaite / peut accéder?

— Feuermurmel
source

quelle est la commande exacte que vous exécutez lorsque vous étendez? Les têtes LVM reçoivent généralement 2 Mo, ce qui correspond à la taille de votre écart.

— Bratchley

La plus petite taille signalée par hdparmest le plus grand nombre qui est un multiple de 255 * 63 secteurs et inférieur à la taille réelle. Cette contrainte est due au format cylindre / culasse / secteurs de l'interface BIOS vieille de 30 ans. La nouvelle interface LBA48 peut très bien signaler la taille de votre disque. Je n'ai aucune idée pourquoi Linux utilise la taille CHS pour quoi que ce soit.

— Gilles 'SO- arrête d'être méchant'

J'ai étiqueté les différentes valeurs entre crochets pour y faire référence facilement.

— Feuermurmel

@JoelDavis J'ai étendu le VG en utilisant une plaine vgextend <vg-name> /dev/sdf. LVM fait exactement ce que j'attends. pvdisplaydit même que 1,71 MiB sont inutilisables, ce qui est exactement la taille de la différence entre [lvm] et [lba].

— Feuermurmel

@Feuermurmel veuillez modifier votre question pour fournir des informations supplémentaires - ne pas utiliser de commentaires.

— guntbert

Le problème clé ici est votre Free PEvaleur. Remarquez comment il est dit que seulement 100 extensions sont gratuites? Cela signifie que vous ne pourrez pas l'étendre. Si vous effectuez un vgscan, pvscan, puis un vgdisplay (également vgs), vous verrez probablement que votre appareil fait déjà partie d'un vg (et probablement de lv (s) également), c'est pourquoi les extensions ne sont pas gratuites.

Pourriez-vous fournir la sortie de:

vgscan;pvscan;vgdisplay;vgs

vous devriez être en mesure d'obtenir 400 Mo supplémentaires en fonction de la taille de vos extensions et de la quantité gratuite.

— Khrystoph
source

Oui, ce PV a déjà 238367 PE alloués à un LV. Ces 100 extensions sont gratuites car j'ai réduit le LV après que le mappeur de périphériques se soit plaint que le mappage demandé par LVM était hors de portée. Mon problème est que le PV créé par LVM est en fait plus grand que le disque physique. Ce disque en question ne fait plus partie du système, je ne peux donc pas fournir la sortie que vous avez demandée.

— Feuermurmel