+++ This bug was initially created as a clone of Bug #820116 +++ Description of problem: If there is PV with zero PE count in the VG, vgcfgrestore on the VG fails saying "Floating point exception", which is caused by division by zero. Background: We are using LVM heavily for storage of block device backups. Because the PVs are usually very busy and metadata manipulation requires direct access to the metadata sector (may take considerable time to complete), we have created a metadata-only PV on a separate drive. Version-Release number of selected component (if applicable): LVM version: 2.02.87(2)-RHEL6 (2011-10-12) Library version: 1.02.66-RHEL6 (2011-10-12) Driver version: 4.22.6 How reproducible: Always Steps to Reproduce: create /dev/<metadata_device> with size 200M create /dev/<data_device> of any size pvcreate --metadatasize 128m /dev/<metadata_device> pvcreate --metadatasize 128m /dev/<data_device> vgcreate -s 128m myVG /dev/<metadata_device> /dev/<data_device> vgcfgbackup myVG vgcfgrestore myVG Actual results: Last command fails with "Floating point exception" error. Expected results: vgcfgrestore should successfully write VG metadata Additional info: This issue may be worked around by omitting the zero-length PV from the backup file. See file contents below. We have solved this for our case using the above workaround and making the metadata PV bigger and setting allocable to N afterwards. Backup file contents: # Generated by LVM2 version 2.02.87(2)-RHEL6 (2011-10-12): Wed May 9 10:13:28 2012 contents = "Text Format Volume Group" version = 1 description = "vgcfgbackup -f myvg.vg myvg" creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 creation_time = 1336551208 # Wed May 9 10:13:28 2012 myvg { id = "ouGQeP-8bPl-udT8-lm8a-Nd3A-WprB-pOGXfj" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 262144 # 128 Megabytes max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "hbMvQA-zTeD-CKPc-WE8o-umlm-Z6GJ-iyALRr" device = "/dev/vg_test/pv1" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 20971520 # 10 Gigabytes pe_start = 264192 pe_count = 78 # 9.75 Gigabytes } pv1 { id = "K1BwfU-2LuG-8aeW-IXHR-RLf7-d36V-DMERDr" device = "/dev/vg_test/pv_metadata" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 409600 # 200 Megabytes pe_start = 264192 pe_count = 0 # 0 Kilobytes } } } Backup file for workaround: # Generated by LVM2 version 2.02.87(2)-RHEL6 (2011-10-12): Wed May 9 10:13:28 2012 contents = "Text Format Volume Group" version = 1 description = "vgcfgbackup -f myvg.vg myvg" creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 creation_time = 1336551208 # Wed May 9 10:13:28 2012 myvg { id = "ouGQeP-8bPl-udT8-lm8a-Nd3A-WprB-pOGXfj" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 262144 # 128 Megabytes max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "hbMvQA-zTeD-CKPc-WE8o-umlm-Z6GJ-iyALRr" device = "/dev/vg_test/pv1" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 20971520 # 10 Gigabytes pe_start = 264192 pe_count = 78 # 9.75 Gigabytes } } } --- Additional comment from agk on 2012-05-09 08:51:02 EDT --- Thanks for reporting this! Peter has committed a fix for the next upstream release (2.02.96) and this will be picked up by RHEL6.4: http://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=501a2c04a4cb009a4c6497cd601801b2fe32fb4e
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Fixed in lvm2-2.02.88-8.el5
(09:13:27) [root@node01:/usr/tests/sts-rhel5.8/bin]$ pvcreate /dev/sdf1 --metadatasize 128m Writing physical volume data to disk "/dev/sdf1" Physical volume "/dev/sdf1" successfully created (09:13:53) [root@node01:/usr/tests/sts-rhel5.8/bin]$ pvcreate /dev/sdf2 --metadatasize 128m Writing physical volume data to disk "/dev/sdf2" Physical volume "/dev/sdf2" successfully created (09:14:18) [root@node01:/usr/tests/sts-rhel5.8/bin]$ vgcreate -s 128m myVG /dev/sdf1 /dev/sdf2 Volume group "myVG" successfully created (09:14:40) [root@node01:/usr/tests/sts-rhel5.8/bin]$ vgcfgbackup myVG Volume group "myVG" successfully backed up. Backup file contents: =============================================================================== # Generated by LVM2 version 2.02.88(2)-RHEL5 (2012-01-20): Tue Jun 5 09:15:20 2012 contents = "Text Format Volume Group" version = 1 description = "Created *after* executing 'vgs'" creation_host = "node01" # Linux node01 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 creation_time = 1338905720 # Tue Jun 5 09:15:20 2012 myVG { id = "Rm7bEs-oKYQ-nU8f-anuG-FvMP-M0wu-V2RETe" seqno = 2 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 262144 # 128 Megabytes max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "QgvzP3-Anvk-lhmm-BJ8T-oox1-Bw7K-zDhLrq" device = "/dev/sdf1" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 393184 # 191.984 Megabytes pe_start = 262272 pe_count = 0 # 0 Kilobytes } pv1 { id = "ALkiPq-D63Y-DAjf-Uvq0-7NUk-NP1a-hPragh" device = "/dev/sdf2" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 19605504 # 9.34863 Gigabytes pe_start = 262272 pe_count = 73 # 9.125 Gigabytes } } } =============================================================================== (09:14:58) [root@node01:~]$ vgcfgrestore myVG Restored volume group myVG Tested with the following packages installed: lvm2-2.02.88-8.el5 lvm2-cluster-2.02.88-8.el5 kmod-cmirror-0.1.22-3.el5 cmirror-1.1.39-15.el5 device-mapper-multipath-0.4.7-49.el5 device-mapper-1.02.67-2.el5 device-mapper-event-1.02.67-2.el5 kernel-2.6.18-308.el5 No errors reported.
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-2013-0023.html