RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 737087 - lvcreate rounds 100%FREE incorrectly for very large PVs
Summary: lvcreate rounds 100%FREE incorrectly for very large PVs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Milan Broz
QA Contact: Corey Marthaler
URL:
Whiteboard:
Depends On:
Blocks: 743047
TreeView+ depends on / blocked
 
Reported: 2011-09-09 15:07 UTC by Eric Sandeen
Modified: 2013-03-01 04:10 UTC (History)
10 users (show)

Fixed In Version: lvm2-2.02.87-3.el6
Doc Type: Bug Fix
Doc Text:
If the lvcreate command was used with large PVs while using %FREE, %VG, %PVS or %ORIGIN for size definition, the resulting LV size was incorrectly calculated. This was caused by integer overflow while calculating the percents. The fix provides a better way of calculating the sizes so that the overflow does not occur anymore by using proper typecasting.
Clone Of:
Environment:
Last Closed: 2011-12-06 17:03:04 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1522 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2011-12-06 00:50:10 UTC

Description Eric Sandeen 2011-09-09 15:07:36 UTC
Description of problem:

With 8 large PV:

# pvs
  PV         VG   Fmt  Attr PSize  PFree 
  /dev/loop0      lvm2 a-   72.00t 72.00t
  /dev/loop1      lvm2 a-   72.00t 72.00t
...
  /dev/loop7      lvm2 a-   72.00t 72.00t

In a large VG:

# vgcreate DATA_VG /dev/loop[0-7]
  Volume group "DATA_VG" successfully created
# vgs
  VG      #PV #LV #SN Attr   VSize   VFree  
  DATA_VG   8   0   0 wz--n- 576.00t 576.00t

lvcreate -l 100%FREE sizes things wrong:

# lvcreate -i 8 -I 1024 -l 100%FREE DATA_VG -n DATA_LV 
  Rounding size (22145917 extents) up to stripe boundary size (22145920 extents)
  Logical volume "DATA_LV" created
# lvs
  LV      VG      Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  DATA_LV DATA_VG -wi-a- 84.48t

Note the "84.48t" vs the expected 576t

Version-Release number of selected component (if applicable):

lvm2-2.02.87-2.el6.x86_64


How reproducible:

Every time


Steps to Reproduce:

You'll need an xfs filesystem to host large loopback files.

[code]
#!/bin/bash

for I in `seq 0 7`; do
   truncate --size 72t file$I;
   losetup /dev/loop$I file$I;
done

pvcreate /dev/loop[0-7]
vgcreate DATA_VG /dev/loop[0-7]
lvcreate -i 8 -I 1024 -l 100%FREE DATA_VG -n DATA_LV

pvs
vgs
lvs
[/code]

Comment 3 Corey Marthaler 2011-09-12 20:50:57 UTC
Do we know at what size this bug is, and is not seen? I attempted this with real hardware (1.1T PVs) and didn't see the issue. I may just have to use loopback devices like in comment #0 or the --setphysicalvolumesize option to reproduce in a regression test case.

[root@hayes-03 ~]# pvscan
  PV /dev/etherd/e1.1p1   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p2   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p3   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p4   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p5   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p6   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p7   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  PV /dev/etherd/e1.1p8   VG DATA_VG      lvm2 [1.11 TiB / 1.11 TiB free]
  Total: 9 [8.94 TiB] / in use: 9 [8.94 TiB] / in no VG: 0 [0   ]

[root@hayes-03 ~]# vgs
  VG         #PV #LV #SN Attr   VSize  VFree
  DATA_VG      8   0   0 wz--nc  8.87t 8.87t

[root@hayes-03 ~]# lvcreate -i 8 -I 1024 -l 100%FREE DATA_VG -n DATA_LV 
  Logical volume "DATA_LV" created

[root@hayes-03 ~]# lvs
  LV      VG         Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  DATA_LV DATA_VG    -wi-a-  8.87t

Comment 4 Milan Broz 2011-09-15 13:15:34 UTC
Seems like simple overflow somewhere, no need to use stripes.

# lvcreate -l 100%FREE DATA_VG -n DATA_LV
  Logical volume "DATA_LV" created

# lvs
  LV      VG      Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  DATA_LV DATA_VG -wi-a- 84.48t                                      

# pvs
  PV              VG      Fmt  Attr PSize  PFree 
  /dev/mapper/pv0 DATA_VG lvm2 a--  72.00t     0 
  /dev/mapper/pv1 DATA_VG lvm2 a--  72.00t 59.52t
  /dev/mapper/pv2 DATA_VG lvm2 a--  72.00t 72.00t
  /dev/mapper/pv3 DATA_VG lvm2 a--  72.00t 72.00t
  /dev/mapper/pv4 DATA_VG lvm2 a--  72.00t 72.00t
  /dev/mapper/pv5 DATA_VG lvm2 a--  72.00t 72.00t
  /dev/mapper/pv6 DATA_VG lvm2 a--  72.00t 72.00t
  /dev/mapper/pv7 DATA_VG lvm2 a--  72.00t 72.00t

Comment 5 Milan Broz 2011-09-15 15:30:01 UTC
Fixed upstream. Maybe this one will need zstream update, all %FREE, %VG etc can overflow because of uint32_t is used for extent count...

Comment 6 Eric Sandeen 2011-09-15 21:45:45 UTC
Just for posterity, might want to fix the summary of the bug back to "very large" PVs, if stripes aren't the cause....

Comment 8 Corey Marthaler 2011-10-05 16:25:26 UTC
lvcreate now uses all 504T, marking verified in the latest rpms. 

[root@hayes-01 xfs]# pvcreate /dev/loop[1234567]
  Writing physical volume data to disk "/dev/loop1"
  Physical volume "/dev/loop1" successfully created
  Writing physical volume data to disk "/dev/loop2"
  Physical volume "/dev/loop2" successfully created
  Writing physical volume data to disk "/dev/loop3"
  Physical volume "/dev/loop3" successfully created
  Writing physical volume data to disk "/dev/loop4"
  Physical volume "/dev/loop4" successfully created
  Writing physical volume data to disk "/dev/loop5"
  Physical volume "/dev/loop5" successfully created
  Writing physical volume data to disk "/dev/loop6"
  Physical volume "/dev/loop6" successfully created
  Writing physical volume data to disk "/dev/loop7"
  Physical volume "/dev/loop7" successfully created

[root@hayes-01 xfs]# vgcreate DATA_VG /dev/loop[1234567]
  Volume group "DATA_VG" successfully created

[root@hayes-01 xfs]# vgs
  VG         #PV #LV #SN Attr   VSize   VFree  
  DATA_VG      7   0   0 wz--n- 504.00t 504.00t

[root@hayes-01 xfs]# pvs
  /dev/loop1         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop2         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop3         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop4         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop5         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop6         DATA_VG    lvm2 a--  72.00t 72.00t
  /dev/loop7         DATA_VG    lvm2 a--  72.00t 72.00t

[root@hayes-01 xfs]# lvcreate -l 100%FREE DATA_VG -n DATA_LV
  Logical volume "DATA_LV" created

[root@hayes-01 xfs]# lvs 
  LV      VG         Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  DATA_LV DATA_VG    -wi-a- 504.00t                                      


2.6.32-203.el6.x86_64

lvm2-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
lvm2-libs-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
lvm2-cluster-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
udev-147-2.40.el6    BUILT: Fri Sep 23 07:51:13 CDT 2011
device-mapper-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-libs-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-event-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
device-mapper-event-libs-1.02.66-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011
cmirror-2.02.87-3.el6    BUILT: Wed Sep 21 09:54:55 CDT 2011

Comment 9 Peter Rajnoha 2011-10-27 10:42:38 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
If the lvcreate command was used with large PVs while using  %FREE, %VG, %PVS or %ORIGIN for size definition, the resulting LV size was incorrectly calculated. This was caused by integer overflow while calculating the percents. The fix provides a better way of calculating the sizes so that the overflow does not occur anymore by using proper typecasting.

Comment 10 errata-xmlrpc 2011-12-06 17:03:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1522.html


Note You need to log in before you can comment on or make changes to this bug.