2

I am trying to install a CentOS 7.4 system using a kickstart file and have received the following error: 'new lv is too large to fit in free space'

There is an additional message that 752.85MiB is needed.

Here are the relevant parts of the kickstart file:

part pv.00 --size=77824 --asprimary
volgroup vg00 pv.00
logvol / --fstype=ext4 --name=lv_root --vgname=vg00 --size=40960
logvol /tmp --fstype=ext4 --name=lv_tmp --vgname=vg00 --size=16384 --fsoptions="nodev,noexec,nosuid"
logvol /var --fstype=ext4 --name=lv_var --vgname=vg00 --size=16384 --fsoptions="nodev,nosuid"
logvol swap --name=lv_swap --vgname=vg00 --size=4096

As you can see, the total size of the logical volumes is equal to the size of the physical volume : 40960 + 16384 + 16384 + 4096 = 77824

Clearly there is some overhead or metadata that is taking up part of the physical volume or the volume group, but it's unclear how that is being calculated.

I have spent all morning Googling this, and couldn't find any information, even in RedHat's Advanced LVM Configuration guides.

For the purposes of this answer, assume that --grow is not an option and I need to know the exact calculation (there will be another physical volume after this one that needs to grow, so this one needs to be a fixed size).

Michael Day
  • 23
  • 1
  • 5
  • What about just trying to setup lv's with the required sizes in a pv with enough space and then having a look how much has been taken by metadata and how much is left? I mean there is the possibility that "nobody knows" how much space the metadata will take because the SW "just does it" and in the and as much space was taken as was necessary... - seriously. – Tomáš Pospíšek Dec 11 '17 at 21:47
  • I guess your comment was too long and so the end of it was cut off... – Tomáš Pospíšek Dec 11 '17 at 22:44
  • @TomášPospíšek I tried what you suggested, and I think there is some type of bug in the Anaconda calculation. I reduced the size of one of the partitions by 1GiB to be safe and the installation succeeded. When I checked pvdisplay, here is what I saw: `PV Size 76.00 GiB / not usable 4.00 MiB PE Size 4.00 MiB Total PE 19455` 19455 * 4 = 77820. So the physical volume only had 4MB of unusable space (metadata?). When I used the original settings and just removed 4MiB from one partition, it succeeded. So Anaconda was lying about needing 752.85MiB more space, it only needed 4 MiB. – Michael Day Dec 11 '17 at 22:50
  • Isn't there also confusion about what those numbers are (Byte? KB? MB? etc.)? – Tomáš Pospíšek Dec 11 '17 at 22:53
  • @TomášPospíšek There is no confusion there. The RedHat manuals use MiB (MebiByte) which is defined as 1024 KiB (not to be confused with the other version hard drive manufacturers use to inflate storage numbers) – Michael Day Dec 18 '17 at 19:55

2 Answers2

2

  • By default, LVM2 metadata is 1 MiB per physical volume. You use pvs -o +pe_start to find out exactly where the payload starts.

  • Volume groups and logical volumes have no metadata overhead; only physical volumes carry metadata.

  • Also by default, LVM uses physical extents of 4 MiB.

The end result is that if for aesthetic reasons you want pvdisplay to show "not usable 0" then you must:

  • Either make each physical volume a multiple of 4 MiB + 1 MiB,

  • Or you create your volume groups with -s 1m, to have physical extents of 1 MiB.

Sources:

  • The default alignment of the data area (reflected in the start sector of the payload area pvs -o +pe_start) is 1 MiB in accordance with this commit. This is actually a configurable parameter, see the manual page for lvm.conf; it can of course be controlled per physical volume at physical volume creation time.

  • The default physical extent size is documented in the manual page for vgcreate:

    -s, --physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE]
    Sets the physical extent size on physical volumes of this volume group. A size suffix (k for kilobytes up to t for terabytes) is optional, megabytes is the default if no suffix is present. The value must be at least 1 sector for LVM2 format (where the sector size is the largest sector size of the PVs currently used in the VG) or 8KiB for LVM1 format and it must be a power of 2. The default is 4 MiB.

AlexP
  • 10,217
  • 32
  • 41
  • This is a great answer. I tried Googling all sorts of combinations of LVM2, metadata, 1 MiB etc to find out the authoritative source documentation online where you found this answer and didn't get any good results. I would expect that is something that RedHat would have documented. Do you have a link to where you found that? Someone edited my original question and removed my ask for the authoritative link to that info. – Michael Day Dec 18 '17 at 20:02
  • @NathanPeters: See edited answer. In short, the default 4 MiB physical extent size is well documented; the default offset of 1 MiB for the payload is much less well documented, but it *is* somewhat documented and is consistent with actual behavior of `pvcreate`. – AlexP Dec 18 '17 at 22:35
0

The command dmsetup table shows the start position of a LV within its PV. For my PVs on older systems the lowest offset is 384:

start cmd: # dmsetup table | grep '\b384$'
storage-images: 0 62914560 linear 9:9 384
linux0-home: 0 2097152 linear 9:0 384

On newer systems the offset is larger, though:

linuxbackup-rootfs: 0 18874368 linear 9:1 2048

This probably means that depending on the LVM version (or the distro-specific configuration) the first 384 or 2048 sectors are reserved for the PV and VG metadata. There may be metadata at the end of the PV, too (if you enforce that).

If you want to know the relevant value for you then you can simply create a VG and check the used value. But for your purpose it might be enough to just calculate with the larger value.

Hauke Laging
  • 88,146
  • 18
  • 125
  • 174