ドライブのサイズに2つの異なる値があり、それらをdevice-mapperとLVMで調整する方法はなぜですか？

USB経由で1 TBのドライブを接続しています。デバイス全体を占有するLVM 物理ボリュームが含まれています（パーティションテーブルはありません）。PV全体を使用して論理ボリュームを拡張しようとすると、デバイスマッパーは、PVでLVMによって割り当てられたセクションがデバイスよりも大きいと不平を言い始めました。デバイスマッパーからのエラーメッセージ（で示されているdmesg）は、1953320367 [dm]セクターのサイズを報告します。

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

しかし、LVMは238467の物理エクステントを持つPVを作成しました。これは1953521664 [lvm]セクターです（約100 MB以上）。

$ 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

hdparm -gIデバイスで実行すると、デバイスのサイズの2つの値が表示されます。geometryの下には、device-mapperによって報告されるデバイスのサイズと同じ値があります。ただし、LBA48ユーザーアドレス可能セクターでは、値1953525168 [lba]があります。これは、PVのPEの結合サイズよりも1 PE未満です。これは、これが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
...

今私の質問に：

カーネルのさまざまな部分で使用されるデバイスのサイズに2つの異なる値があるのはなぜですか？
そして、この状況をどのように処理/修正して、デバイスマッパーがアクセスできる/許可するスペースよりも大きいPVをLVMが作成しないようにしますか？

— フォイアマーメル
ソース

拡張するときに実行している正確なコマンドは何ですか？LVMヘッドには通常、2MBが割り当てられますが、これは矛盾の程度です。

— ブラッチリー14年

報告される小さいサイズhdparmは、255 * 63セクターの倍数であり、実際のサイズより小さい最大数です。この制約は、30年前のBIOSインターフェースのシリンダー/ヘッド/セクターのフォーマットによるものです。新しいLBA48インターフェイスは、ディスクのサイズを問題なく報告できます。Linuxが何にでもCHSサイズを使用する理由がわかりません。

— ジル 'SO-悪であるのをやめる' 14年

簡単に参照できるように、さまざまな値に角かっこでラベルを付けました。

— Feuermurmel 14年

@JoelDavisプレーンを使用してVGを拡張しましたvgextend <vg-name> /dev/sdf。LVMはまさに私が期待することをします。1.71 MiBはunusabeであるとpvdisplayさえ述べており、これはまさに[lvm]と[lba]の差の大きさです。

— Feuermurmel 14年

@Feuermurmelは質問を編集して追加情報を提供してください。コメントは使用しないでください。

— ガントベルト

ここで重要な問題はあなたのFree PE価値です。100エクステントだけが無料であると言っていることに注意してください。つまり、拡張することはできません。vgscan、pvscan、およびvgdisplay（およびvgs）を実行すると、デバイスが既にvgの一部であることがわかります（おそらくlvも同様です）。これがエクステントが空いていない理由です。

次からの出力を提供してもらえますか？

vgscan;pvscan;vgdisplay;vgs

エクステントのサイズと空き領域の数に基づいて、さらに400MBを取得できるはずです。

— クリストフ
ソース

はい、そのPVにはすでに238367 PEがLVに割り当てられています。デバイスマッパーがLVMから要求されたマッピングが範囲外であると不平を言った後、LVを縮小したため、これらの100の拡張は無料です。私の問題は、LVMによって作成されたPVが実際には物理ディスクよりも大きいことです。問題のディスクはもはやシステムの一部ではないため、要求した出力を提供できません。

— Feuermurmel