Description of problem: Went setting the maximum number of PVs that can be added to a VG the behavior is inconsistent. If I do (2**32-1)... # vgchange -p 4294967295 foo Volume group "foo" successfully changed It reports # vgs -o+max_pv VG #PV #LV #SN Attr VSize VFree MaxPV foo 1 0 0 wz--n- 18.00g 18.00g 4294967295 which look fine If I do (2**32) # vgchange -p 4294967296 foo Volume group "foo" successfully changed It reports # vgs -o+max_pv VG #PV #LV #SN Attr VSize VFree MaxPV foo 1 0 0 wz--n- 18.00g 18.00g 0 Which seems reasonable I guess as '0' == unlimited, lvm could reject the value too. However, when I do (2**64-1) # vgchange -p 18446744073709551615 foo Volume group "foo" successfully changed I get # vgs -o+max_pv VG #PV #LV #SN Attr VSize VFree MaxPV foo 1 0 0 wz--n- 18.00g 18.00g 4294967295 Which seems inconsistent based on the previous behavior If I do (2**64) I get # vgchange -p 18446744073709551616 foo Invalid argument for --maxphysicalvolumes: 18446744073709551616 Error during parsing of command line. Version-Release number of selected component (if applicable): LVM version: 2.02.132(2) (2015-09-22) Library version: 1.02.109 (2015-09-22) Driver version: 4.33.0 How reproducible: Always Steps to Reproduce: See above Actual results: Inconsistent behavior Expected results: Either we should reject the value when it's too big or we set it to '0' when it overflows a uint32_t. Additional info:
Setting the max lv has the same inconsistent behavior.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Should be fixed upstream with: https://www.redhat.com/archives/lvm-devel/2017-January/msg00000.html https://www.redhat.com/archives/lvm-devel/2017-January/msg00001.html Only sensible resultion here is to give an error on anything outside of the supported range <0, UINT32_MAX>.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.