Bug 500898 - RFE: give better message when pvmove is already in progress on requested VG
RFE: give better message when pvmove is already in progress on requested VG
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.8
All Linux
low Severity medium
: rc
: ---
Assigned To: Peter Rajnoha
Cluster QE
: FutureFeature
Depends On:
Blocks: 500899
  Show dependency treegraph
 
Reported: 2009-05-14 15:04 EDT by Corey Marthaler
Modified: 2013-01-10 21:31 EST (History)
9 users (show)

See Also:
Fixed In Version: lvm2-2.02.42-8.el4
Doc Type: Enhancement
Doc Text:
The pvmove utility has been updated to produce a more descriptive error message when when all source logical volumes (LVs) are skipped.
Story Points: ---
Clone Of:
: 500899 (view as bug list)
Environment:
Last Closed: 2011-02-16 08:56:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2009-05-14 15:04:21 EDT
Description of problem:
If you have a pvmove running on a VG and attempt another one from a different device (within the same VG), lvm will tell you there's nothing to move when in reality that's not true. lvm just doesn't allow more than one pvmove at a time to a single VG 

[root@grant-02 ~]# pvscan | grep ONE
  PV /dev/sdb1   VG ONE          lvm2 [45.41 GB / 5.41 GB free]
  PV /dev/sdb3   VG ONE          lvm2 [45.41 GB / 5.41 GB free]
  PV /dev/sdb6   VG ONE          lvm2 [45.41 GB / 25.41 GB free]
  PV /dev/sdc1   VG ONE          lvm2 [45.41 GB / 45.41 GB free]
  PV /dev/sdc3   VG ONE          lvm2 [45.41 GB / 5.41 GB free]
  PV /dev/sdc6   VG ONE          lvm2 [45.41 GB / 45.41 GB free]

[root@grant-01 ~]# pvmove -v /dev/sdb1 /dev/sdb3
    Finding volume group "ONE"
    Executing: /sbin/modprobe dm-cmirror  
    Archiving volume group "ONE" metadata (seqno 17).
    Creating logical volume pvmove0
    Moving 5120 extents of logical volume ONE/lv_one_1
    Moving 5120 extents of logical volume ONE/lv_one_2
    Updating volume group metadata
    Creating volume group backup "/etc/lvm/backup/ONE" (seqno 18).
    Checking progress every 15 seconds
  /dev/sdb1: Moved: 2.3%
  /dev/sdb1: Moved: 4.2%
  /dev/sdb1: Moved: 6.2%
  /dev/sdb1: Moved: 8.2%
  /dev/sdb1: Moved: 10.1%
  [...]
  /dev/sdb1: Moved: 96.3%
  /dev/sdb1: Moved: 98.2%
  /dev/sdb1: Moved: 100.0%
    Removing temporary pvmove LV
    Writing out final volume group after pvmove
    Creating volume group backup "/etc/lvm/backup/ONE" (seqno 23).

# Before the above finishes
[root@grant-02 ~]# pvmove -v /dev/sdb6 /dev/sdc1
    Finding volume group "ONE"
    Executing: /sbin/modprobe dm-cmirror  
    Archiving volume group "ONE" metadata (seqno 18).
    Creating logical volume pvmove1
  Skipping locked LV lv_one_1
  Skipping locked LV lv_one_2
  Skipping mirror LV pvmove0
  No data to move for ONE

The "Skipping mirror LV pvmove0" is a clue that one is already in progress. It would be nice if lvm just said something to that effect.

Once the first one finishes, I'm able to do the pvmove that just had "No data to move"

[root@grant-02 ~]# pvmove -v /dev/sdb6 /dev/sdc1
    Finding volume group "ONE"
    Executing: /sbin/modprobe dm-cmirror  
    Archiving volume group "ONE" metadata (seqno 23).
    Creating logical volume pvmove0
    Moving 2560 extents of logical volume ONE/lv_one_1
    Moving 2560 extents of logical volume ONE/lv_one_2
    Updating volume group metadata
    Creating volume group backup "/etc/lvm/backup/ONE" (seqno 24).
    Checking progress every 15 seconds
  /dev/sdb6: Moved: 5.1%
  /dev/sdb6: Moved: 9.7%


Version-Release number of selected component (if applicable):
lvm2-2.02.37-3.el4

How reproducible:
Everytime
Comment 1 Peter Rajnoha 2009-05-29 12:08:52 EDT
Actually, pvmove allows more than one pvmove in a VG. The problem in here is that physical extents that belong to one LV can be placed over many PVs (just like lv_one_1 and lv_one_2 in the example above).

When moving a PV /dev/sdb1 containing physical extents for those LVs, we can't move physical extents on another PV /dev/sdb6 that belong to the same LVs. If there are physical extents for those LVs only on /dev/sdb6 then the message is right in this situation -- actually there aren't any other physical extents to move.

Maybe we should extend the message "Skipping locked LV ..." to "Skipping physical extents for locked LV ...".
Comment 2 Corey Marthaler 2009-05-29 12:29:36 EDT
It's the "No data to move for" message that confuses me. 

Sounds like there is data to move, it's just that we're not allowed to do so at the moment. I'd really like that message changed if possible.
Comment 3 Peter Rajnoha 2009-05-29 12:48:51 EDT
Sure, I think we could change the message quite easily for that specific situation (all PEs skipped on the PV because of the LV locks).
Comment 4 Peter Rajnoha 2010-05-17 09:14:50 EDT
The commit is f69e8e3606c56b2c5affff577010b712dff240bb (Fri, 4 Dec 2009)
Comment 5 Milan Broz 2010-10-21 13:16:11 EDT
Fixed in lvm2-2.02.42-8.el4.
Comment 8 Corey Marthaler 2011-01-17 19:05:15 EST
Multiple pvmoves now work simultaneously. As a result, I'm unable to reproduce this message to see if it's any better. Marking verified.

2.6.9-94.ELsmp

lvm2-2.02.42-9.el4    BUILT: Thu Oct 21 15:49:57 CDT 2010
lvm2-cluster-2.02.42-9.2.el4    BUILT: Mon Jan 17 16:43:18 CST 2011
device-mapper-1.02.28-3.el4    BUILT: Thu Mar  4 14:48:16 CST 2010
cmirror-1.0.2-1.el4    BUILT: Thu Feb 26 15:29:27 CST 2009
cmirror-kernel-2.6.9-43.14.el4    BUILT: Wed Dec 22 16:24:19 CST 2010
Comment 9 Jaromir Hradilek 2011-01-20 07:50:08 EST
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The pvmove utility has been updated to produce a more descriptive error message when when all source logical volumes (LVs) are skipped.
Comment 10 errata-xmlrpc 2011-02-16 08:56:27 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0236.html

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