I say CLOSE NOTABUG/WONTFIX:

- this would break a few [test] scripts.
- adding more prompts is seldom a solution. Users will learn from webs to overuse --force and --yes.

If one wants the same size, why using the option at all?

If one goes into trouble entering the size it is likely different size is desired. Unless the requested size is larger than physical device, there is no problem.

Also I think the man page is clear enough:

       --setphysicalvolumesize size
              Overrides  the  automatically-detected  size  of the PV.  Use with
              care.

Is this driven by user requests/customer cases or just a random idea?
I searched web and failed to found any evidence of confusion or a lot of problem reports.

I admit we need to educate users to read the manpage before copypasting random bits from web. Maybe add an universal option `--i-swear-i-have-read-and-understood-the-manpage`, or sign each command with a key linked to RHCA account, or a quiz about LVM before executing any command would do the trick. "ERROR: You need score at lest 80/100 to execute this command."

Marion,

It's driven my numerous customer cases.  In general, the customer will go san-side and increase a lun size, for example, from 30G to 40G.  They'll rescan the new size in through sd and maybe multipath/dm, then they will run the command 'pvresize --setphysicalvolumesize 40G'.  At this point, the LVM stack will off by just a bit, and we'll lose it.

I failed to mention earlier that we spoke with Alasdair and Zdenek about this prior to opening this RFE.  I mentioned a blaring warning in the man page (this would not take care of --help).  Then Alasdair noted that a warning of size difference between PV and underlying device was a possible solution.  He also noted the possibility of changing '--setphysicalvolumesize' to 'overridephysicalvolumesize', or something similar.  Apologies for not mentioning this in my initial update.

The command is being used incorrectly, yes, but the frequency of incorrect usage, as is, is too high to be ignored.  Too many customer cases have come in where this has occurred, and we need to make it very clear that this option can break the stack easily.

Hello Marion,

I'd like to add, we often see this case where the customer calculates a size of the PV thats a few MB more than what LVM has. It can often have to do with other small partitions existing that the customer forgets, or even something as simple as using a different unit than LVM while converting from GB or TB to MB. Even a slightly larger size than what LVM has creates huge issues. At least can we round off to the largest size of the available space instead of allowing them to create larger pv's than the device?

nikhil.

There is no problem adding prompt in this particular case.

Script should not be really using such dangerous command - the prompt is 'rather' missing.

So 'pvchange' will require prompt confirmation.

I think we can agree on adding a confirmation prompt when the specified size does not match the device size.  In effect, this means giving a prompt whenever the option is used in the way originally intended.  --yes will suppress the prompt.  Possibly different prompts for the two cases, smaller/larger.

Patch to prompt when sizes don't match and to sort out some of the numbers shown in the messages.

https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=cbc69f8c693edf0d1307c9447e2e66d07a04bfe9

https://www.redhat.com/archives/lvm-devel/2017-April/msg00109.html

Testing should cover both orphans and PVs already in VGs for the cases: smaller, matching/default, larger and multiple PVs changed in one command.

(I've not looked at pvcreate yet.)

Similar approach applied to pvcreate, but more complicated because that code has already been fixed not to prompt inside the library or while locks are held:

https://www.redhat.com/archives/lvm-devel/2017-April/msg00117.html

https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=4f9ff14508084789c731e99d8921c052da694319

Adding QA ack for 7.4.

Testing will verify if user is prompted when pv size specified in 'pvresize --setphysicalvolumesize' or 'pvcreate --setphysicalvolumesize' commands does not match the size of a backing device. This change applies to both orphaned pvs and members of vg. Prompt is skipped when --yes option is used (--force should not be required)

added pm_ack, thought this is rather late in the process for what is essentially a feature enhancement.

Verified with latest rpms.

'pvresize' now prompts user for confirmation when real device size and requested pv size don't match. '-y or --yes' options override the prompt. Output has been changed as well to better inform user about whether the size requested is lower or exceeding the size of specified device.


BEFORE PATCH:

##No prompt with any of pvresize actions (higher/lower/equal sizes)
[root@virt-368 ~]# pvresize --setphysicalvolumesize 100G /dev/sdj
  WARNING: /dev/sdj: Overriding real size. You could lose data.
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
[root@virt-368 ~]# pvresize --setphysicalvolumesize 1G /dev/sdj
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
[root@virt-368 ~]# pvresize --setphysicalvolumesize 40G /dev/sdj
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized


AFTER PATCH:

Orphaned PV:

[root@virt-365 ~]# pvs
  PV         VG            Fmt  Attr PSize  PFree 
  /dev/sda   vg            lvm2 a--  39.99g 39.99g
  /dev/sdb   vg            lvm2 a--  39.99g 39.99g
  /dev/sdc   vg            lvm2 a--  39.99g 39.99g
  /dev/sdd   vg            lvm2 a--  39.99g 39.99g
  /dev/sde   vg            lvm2 a--  39.99g 39.99g
  /dev/sdf   vg            lvm2 a--  39.99g 39.99g
  /dev/sdg   vg            lvm2 a--  39.99g 39.99g
  /dev/sdh   vg            lvm2 a--  39.99g 39.99g
  /dev/sdi   vg            lvm2 a--  39.99g 39.99g
  /dev/sdj                 lvm2 ---  40.00g 40.00g
  /dev/vda2  rhel_virt-365 lvm2 a--  <7.00g     0 

##Prompt added for cases when higher physical size is requested:

[root@virt-365 ~]# pvresize --setphysicalvolumesize 100G /dev/sdj
  WARNING: /dev/sdj: Overriding real size 40.00 GiB. You could lose data.
/dev/sdj: Requested size 100.00 GiB exceeds real size 40.00 GiB. Proceed?  [y/n]: n
  Physical Volume /dev/sdj not resized.
  0 physical volume(s) resized / 1 physical volume(s) not resized

##Prompt added for cases when lower physical size is requested:

[root@virt-365 ~]# pvresize --setphysicalvolumesize 1G /dev/sdj
/dev/sdj: Requested size 1.00 GiB is less than real size 40.00 GiB. Proceed?  [y/n]: n
  Physical Volume /dev/sdj not resized.
  0 physical volume(s) resized / 1 physical volume(s) not resized

## -y | --yes option overrides the prompt (force is not needed)

[root@virt-365 ~]# pvresize --setphysicalvolumesize 100G /dev/sdj -y
  WARNING: /dev/sdj: Overriding real size 40.00 GiB. You could lose data.
  WARNING: /dev/sdj: Pretending size is 209715200 not 83886080 sectors.
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

## -y | --yes option overrides the prompt (force is not needed)

[root@virt-365 ~]# pvresize --setphysicalvolumesize 1G /dev/sdj -y
  WARNING: /dev/sdj: Pretending size is 2097152 not 83886080 sectors.
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

##No prompt when device size and requested pv size match:

[root@virt-365 ~]# pvresize --setphysicalvolumesize 40G /dev/sdj
  Physical volume "/dev/sdj" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

##Same commands but with PV which is a member of a VG:

[root@virt-365 ~]# pvs
  PV         VG            Fmt  Attr PSize  PFree 
  /dev/sda   vg            lvm2 a--  39.99g 39.99g
  /dev/sdb   vg            lvm2 a--  39.99g 39.99g
  /dev/sdc   vg            lvm2 a--  39.99g 39.99g
  /dev/sdd   vg            lvm2 a--  39.99g 39.99g
  /dev/sde   vg            lvm2 a--  39.99g 39.99g
  /dev/sdf   vg            lvm2 a--  39.99g 39.99g
  /dev/sdg   vg            lvm2 a--  39.99g 39.99g
  /dev/sdh   vg            lvm2 a--  39.99g 39.99g
  /dev/sdi   vg            lvm2 a--  39.99g 39.99g
  /dev/sdj                 lvm2 ---  40.00g 40.00g
  /dev/vda2  rhel_virt-365 lvm2 a--  <7.00g     0 

[root@virt-365 ~]# pvresize --setphysicalvolumesize 100G /dev/sda
  WARNING: /dev/sda: Overriding real size 40.00 GiB. You could lose data.
/dev/sda: Requested size 100.00 GiB exceeds real size 40.00 GiB. Proceed?  [y/n]: n
  Physical Volume /dev/sda not resized.
  0 physical volume(s) resized / 1 physical volume(s) not resized

[root@virt-365 ~]# pvresize --setphysicalvolumesize 1G /dev/sda
/dev/sda: Requested size 1.00 GiB is less than real size 40.00 GiB. Proceed?  [y/n]: n   
  Physical Volume /dev/sda not resized.
  0 physical volume(s) resized / 1 physical volume(s) not resized

[root@virt-365 ~]# pvresize --setphysicalvolumesize 100G /dev/sda -y
  WARNING: /dev/sda: Overriding real size 40.00 GiB. You could lose data.
  WARNING: /dev/sda: Pretending size is 209715200 not 83886080 sectors.
  Physical volume "/dev/sda" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

[root@virt-365 ~]# pvresize --setphysicalvolumesize 1G /dev/sda -y
  WARNING: Device /dev/sda has size of 83886080 sectors which is smaller than corresponding PV size of 209698816 sectors. Was device resized?
  One or more devices used as PVs in VG vg have changed sizes.
  WARNING: /dev/sda: Pretending size is 2097152 not 83886080 sectors.
  Physical volume "/dev/sda" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized




3.10.0-671.el7.x86_64

lvm2-2.02.171-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
lvm2-libs-2.02.171-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
lvm2-cluster-2.02.171-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
device-mapper-1.02.140-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
device-mapper-libs-1.02.140-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
device-mapper-event-1.02.140-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
device-mapper-event-libs-1.02.140-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017
device-mapper-persistent-data-0.7.0-0.1.rc6.el7    BUILT: Mon Mar 27 17:15:46 CEST 2017
cmirror-2.02.171-2.el7    BUILT: Wed May 24 16:02:34 CEST 2017

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.

https://access.redhat.com/errata/RHBA-2017:2222