Bug 1280496 - vgchange [-p|-l] <N> <vgname>, inconsistent behavior for large values of N
vgchange [-p|-l] <N> <vgname>, inconsistent behavior for large values of N
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Zdenek Kabelac
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-11-11 17:00 EST by Tony Asleson
Modified: 2017-07-25 15:40 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-25 15:40:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tony Asleson 2015-11-11 17:00:56 EST
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:


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:
Comment 1 Tony Asleson 2015-11-12 11:39:56 EST
Setting the max lv has the same inconsistent behavior.
Comment 2 Jan Kurik 2016-02-24 08:56:49 EST
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:
Comment 3 Zdenek Kabelac 2017-01-03 14:49:54 EST
Should be fixed upstream with:


Only sensible resultion here is to give an error on anything outside of the supported range  <0, UINT32_MAX>.
Comment 4 Fedora End Of Life 2017-07-25 15:28:37 EDT
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.

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