14

I have a 1 TB drive attached via USB. It contains an LVM physical volume filling the entire device (without any partition table). When I tried to extend a logical volume by using the entire PV, the device-mapper started to complain that the section allocated by LVM on the PV is larger than the device. The error message from the device-mapper (as shown by dmesg) reports a size of 1953320367 [dm] sectors:

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

But LVM created a PV with 238467 physical extents, which is 1953521664 [lvm] sectors (which is about 100 MB more):

$ 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

Now if I run hdparm -gI on the device, I can see two values for the size of the device. Under geometry, there's the same value that is reported by the device-mapper as the device's size. But under LBA48 user addressable sectors, there's the value 1953525168 [lba], which is less than one PE larger than the combines size of the PEs of the PV. This makes me think that this is the value that LVM sees:

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

Now to my questions:

  • Why are there two different values for the device's size used by different parts of the kernel?
  • And, how do I handle/fix this situation so that the LVM will not make PVs that are larger than the space the device-mapper is willing/able to access?
techraf
  • 5,831
  • 10
  • 33
  • 51
Feuermurmel
  • 627
  • 1
  • 7
  • 16
  • what's the exact command that you're running when you extend? LVM heads are usually allocated 2MB which is around the size of your discrepancy. – Bratchley Jun 28 '14 at 21:07
  • 7
    The smaller size reported by `hdparm` is the largest number that's a multiple of 255*63 sectors and less than the actual size. This constraint is due to the cylinder/head/sectors format from the 30 year-old BIOS interface. The newer LBA48 interface can report the size of your disk just fine. I have no idea why Linux uses the CHS size for anything. – Gilles 'SO- stop being evil' Jun 28 '14 at 22:46
  • I labeled the different values in square brackets to easily refer to them. – Feuermurmel Jun 29 '14 at 08:09
  • 1
    @JoelDavis I extended the VG using a plain `vgextend /dev/sdf`. LVM does exactly what I expect. `pvdisplay` even says that __1.71 MiB__ are unusabe, which is exactly the size of the difference between [lvm] and [lba]. – Feuermurmel Jun 29 '14 at 08:09
  • 2
    @Feuermurmel please [edit] your question to provide additional information - don't use comments. – guntbert May 17 '15 at 18:55

1 Answers1

1

The key problem here is your Free PE value. Notice how it says that only 100 extents are free? That means that you won't be able to extend it. If you do a vgscan, pvscan, and then a vgdisplay (also vgs) you will probably see that your device is already part of a vg (and likely lv(s) as well), which is why the extents are not free.

Could you provide the output from:

vgscan;pvscan;vgdisplay;vgs

you should be able to get an additional 400MB based on the size of your extents and how many are free.

Khrystoph
  • 459
  • 4
  • 4
  • Yes, that PV already has 238367 PE allocated to an LV. Those 100 extends are free because I shrunk the LV after the device-mapper complained about the mapping requested by LVM being out of range. My problem is that the PV created by LVM is actually _larger_ than the physical disk. That disk in question is no longer part of the system so I can't provide the output you requested. – Feuermurmel Sep 17 '15 at 00:01