Bug 737087 - lvcreate rounds 100%FREE incorrectly for very large PVs
lvcreate rounds 100%FREE incorrectly for very large PVs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.2
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Milan Broz
Corey Marthaler
:
Depends On:
Blocks: 743047
  Show dependency treegraph
 
Reported: 2011-09-09 11:07 EDT by Eric Sandeen
Modified: 2013-02-28 23:10 EST (History)
10 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-06 12:03:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Sandeen 2011-09-09 11:07:36 EDT
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 16:50:57 EDT
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 09:15:34 EDT
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 11:30:01 EDT
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 17:45:45 EDT
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 12:25:26 EDT
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 06:42:38 EDT
    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 12:03:04 EST
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.