(In reply to John Pittman from comment #0)
> Description of problem:
> 
> With no change to the multipath device, pvresize command report repeated
> successful resizes.
> 

John, are you just looking for 'pvresize' to report an error if no resize actually took place?

Hey Jonathan, thanks for looking at this one.  It should just report that it wasn't resized.  So, using mpatha, if a device is actually resized it would say:

[root@host]# pvresize /dev/mapper/mpatha
  Physical volume "/dev/mapper/mpatha" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

And if not:

[root@host]# pvresize /dev/mapper/mpatha
  Physical volume "/dev/mapper/mpatha" changed
  0 physical volume(s) resized / 1 physical volume(s) not resized

My memory may be wrong, but I think this is how it worked at one point.

This isn't a multipath specific issue and happens on any PV.

[root@host-093 ~]# pvcreate /dev/sda1
  Physical volume "/dev/sda1" successfully created.
[root@host-093 ~]# pvs /dev/sda1
  PV         VG Fmt  Attr PSize   PFree  
  /dev/sda1     lvm2 ---  <30.00g <30.00g

[root@host-093 ~]# pvresize /dev/sda1
  Physical volume "/dev/sda1" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
[root@host-093 ~]# pvresize /dev/sda1
  Physical volume "/dev/sda1" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

[root@host-093 ~]# pvs /dev/sda1
  PV         VG Fmt  Attr PSize   PFree  
  /dev/sda1     lvm2 ---  <30.00g <30.00g


My two cents:
I seem to recall past issues/discussions I bought up about other cmds that also reported they "did" something, even if they really didn't, as long as the end result after the cmd was what was expected, it was fine. In this case it would be expected that the PV would now utilize the entirety of available space underneath, even if the available space didn't change. A failure would imply, that the PV does *not* now currently utilize the entirety of available space. Now, if a message was also added that it wasn't resized due to the fact that the underlying space didn't change, then I'd be fine with this fix. 

Something like:
[root@host-093 ~]# lvcreate -L 100M foo
  Logical volume "lvol0" created.
[root@host-093 ~]# lvresize -L 100M /dev/foo/lvol0
  New size (25 extents) matches existing size (25 extents).

I'm inclined  after longer studing this logic - we should change the message:

resized ->  updated.

There is physical write access updating  PV header (not necessarily changing something) but the header is really written.

There is no code detecting if the 'header to be written' is matching what has been already stored on this.


The PV header update may also update VG metadata.

While metadata update is reversible operation (vgcfgrestore) - there is only 1 PV header - so any write of PV header is irreversible.

ATM pvresize updates/rewrites PV header (thus it may fix possibly badly written header from previous command).

My believe here is - the most 'clear' way forward is likely just the update of actual printed message - which means that  resize may or may not have happened.

Adding new code to do a deep check if there is a real need of writing new header because 1 bit of either PV or VG metadata has changed is not worth the complexity for this very occasionally used command.

Pushed updated message for pvresize:

https://www.redhat.com/archives/lvm-devel/2018-June/msg00065.html

The commit on stable branch: e0bfc946cb182a021bb7a74a11ec7ac51ad9a7b0

Verified.

# pvresize /dev/sda
  Physical volume "/dev/sda" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

3.10.0-931.el7.x86_64
lvm2-2.02.180-2.el7

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-2018:3193