Bug 737087
| Summary: | lvcreate rounds 100%FREE incorrectly for very large PVs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Eric Sandeen <esandeen> |
| Component: | lvm2 | Assignee: | Milan Broz <mbroz> |
| Status: | CLOSED ERRATA | QA Contact: | Corey Marthaler <cmarthal> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.2 | CC: | agk, dwysocha, heinzm, jbrassow, mbroz, prajnoha, prockai, pvrabec, thornber, zkabelac |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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 17:03:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 743047 | ||
|
Description
Eric Sandeen
2011-09-09 15:07:36 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 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 Fixed upstream. Maybe this one will need zstream update, all %FREE, %VG etc can overflow because of uint32_t is used for extent count... Just for posterity, might want to fix the summary of the bug back to "very large" PVs, if stripes aren't the cause.... 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
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.
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 |