Bug 500431

This issue still exists in RHEL 5 with at least anaconda version 11.1.2.168-1.  Note that the issue is not limited to small disks.

When calculating the free space available for the size of a logical volume configured with --grow, anaconda does not seem to use (free physical extents) * (physical extent size) for the volume group.  It appears that it uses the size of the physical volume(s) directly when determining how much space is available for the LV.  Given a VG with one PV that is ever so slightly larger than a whole number multiple of the PE size, anaconda will try to size the LV to be one LE larger than is available in the VG.  Specifically, this occurs if the size of the PV is larger than a whole number multiple of the PE size and less than (a whole number multiple of the PE size) + (the size of the LVM metadata that gets written to the PV).  Under these circumstances, anaconda fails to create the LV, giving an error that says there is not enough space in the VG.  (Note that this case likely arises with VGs that have multiple PVs, too, but my specific test case has only one PV in the VG.)
 
Anaconda needs to use (free physical extents) * (physical extent size) when determining the amount of free space that the LV can grow to consume and not the size of the PV partition, because (free physical extents) * (physical extent size) is always less than the size of the partition for the PV of the volume group due to the LVM metadata.
 
Here is a specific example of the problem:
 
A system has the following partition table:
 
Disk /dev/sda: 14593 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0
 
   Device Boot    Start       End   #sectors  Id  System
/dev/sda1   *        63    208844     208782  83  Linux
/dev/sda2        208845    417689     208845  83  Linux
/dev/sda3             0         -          0   0  Empty
/dev/sda4        417690 234436544  234018855   5  Extended
/dev/sda5        417753  29784509   29366757  8e  Linux LVM
/dev/sda6      29784573  59151329   29366757  8e  Linux LVM
/dev/sda7      59151393  73577699   14426307  8e  Linux LVM
 
 
RHEL is installed using a kickstart profile that contains the following disk-related items:
 
bootloader      --location=partition --driveorder=sda
part /boot      --onpart sda1 --fstype ext3
part pv.05      --onpart sda5
part pv.07      --onpart sda7
volgroup system  pv.05 --pesize 4096
volgroup common  pv.07 --pesize 4096
logvol /        --vgname system --name root --size=12288     --fstype ext3
logvol /opt     --vgname system --name opt  --size=1 --grow  --fstype ext3
logvol swap     --vgname common --name swap --size=6016      --fstype swap
logvol /home    --vgname common --name home --size=512       --fstype ext3
logvol /sbux    --vgname common --name sbux --size=1 --grow  --fstype ext3
 
 
Anaconda will fail because it calculates that the size of /sbux should be 516 MB, when there are only 512 MB available in the VG.  Note that anaconda has a propensity for creating partitions and logical volumes in a completely different order than is defined in a kickstart file (a bug, in my opionion, but we won’t go there), so the sequence ends up being that /home and /sbux get created using, respectively, 512 MB and (incorrectly) 516 MB.  Anaconda then attempts to create swap and fails because there are one less PEs available than are needed for swap to be the specified size.
 
Below is the relevant LVM data.  For swap to be 6016 MB, there needs to be 1504 free PEs, but there are only 1503 free PEs because the size of /sbux was mis-calculated to be 516 MB rather than 512 MB.
 
  --- Volume group ---
  VG Name               common
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               6.88 GB
  PE Size               4.00 MB
  Total PE              1760
  Alloc PE / Size       257 / 1.00 GB
  Free  PE / Size       1503 / 5.87 GB
  VG UUID               GcrYLL-6pfm-txkO-Zc6k-9sB2-FUCf-0yo0dB
 
 
  --- Logical volume ---
  LV Name                /dev/common/home
  VG Name                common
  LV UUID                pk2qpR-O5Av-H2WB-4C98-L6Oo-Gm1w-8jTGEM
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                512.00 MB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:1
 
 
  --- Logical volume ---
  LV Name                /dev/common/sbux
  VG Name                common
  LV UUID                aQz57Z-lxSd-EC75-N90k-DkQt-ZzF2-J5e1sb
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                516.00 MB
  Current LE             129
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0
 
Thank you,
Garrick James

(In reply to comment #2)

> When calculating the free space available for the size of a logical volume
> configured with --grow, anaconda does not seem to use (free physical extents) *
> (physical extent size) for the volume group.  It appears that it uses the size
> of the physical volume(s) directly when determining how much space is available
> for the LV.  Given a VG with one PV that is ever so slightly larger than a
> whole number multiple of the PE size, anaconda will try to size the LV to be
> one LE larger than is available in the VG.  Specifically, this occurs if the
> size of the PV is larger than a whole number multiple of the PE size and less
> than (a whole number multiple of the PE size) + (the size of the LVM metadata
> that gets written to the PV).

This seems like perfect description the cause. The case is hard to reproduce, because it requires size of PV to be in the described range. We've met and fixed this case in RHEL 4.8 (commits 6c6a206bd8dfc6910fc4061274bd4f0544 and abe87a2085326af0e9e748b83e6de918d6126dee, and some before). 

Here is updates.img for rhel 5.3 with patch that should solve the issue:
http://rvykydal.fedorapeople.org/updates.500431.img

Created attachment 344161 [details]
patch included in updates.img from previous comment

Srini, did the patched image work for the customer? We'd really love to get some feedback before adding this..

Thank you for checking.
Due to an emergency at the Customer's lead engineer's home. I was not able to connect with the customer last week. Hoping to get an update this week (Wednesday - 27th).

The updates in the updates.img which is attached to this ticket fixed the issue.  Thank you!

-Garrick James

Can you make sure that this fix makes it into the next possible release of RHEL 5?

Thanks.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Should be fixed in version 11.1.2.183 of anaconda.

See also bug 240554.

~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1306.html