Bug 1444205
| Summary: | With no change to the multipath device, pvresize command reports repeated successful resizes | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | John Pittman <jpittman> |
| Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> |
| lvm2 sub component: | Command-line tools | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | low | ||
| Priority: | unspecified | CC: | agk, cmarthal, heinzm, jbrassow, jpittman, loberman, mcsontos, msnitzer, prajnoha, rbednar, rhandlin, thornber, zkabelac |
| Version: | 7.0 | ||
| Target Milestone: | pre-dev-freeze | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.179-3.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 11:02:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1461138, 1546181 | ||
|
Description
John Pittman
2017-04-20 20:33:44 UTC
(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 |