Bug 474650 - Cannot move data using pvmove if the PV has a snapshot or mirror
Cannot move data using pvmove if the PV has a snapshot or mirror
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
All Linux
medium Severity medium
: pre-dev-freeze
: ---
Assigned To: Jonathan Earl Brassow
Cluster QE
: FutureFeature, Reopened
Depends On:
Blocks: 1056252 806907
  Show dependency treegraph
Reported: 2008-12-04 14:03 EST by Forrest Taylor
Modified: 2014-03-18 05:05 EDT (History)
17 users (show)

See Also:
Fixed In Version: lvm2-2.02.100-8.el6.x86_64
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-18 05:05:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 309723 None None None Never

  None (edit)
Description Forrest Taylor 2008-12-04 14:03:10 EST
Description of problem:
pvmove does not move data that is included in a snapshot.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use lvm2 to create a snapshot
2. Attempt to move data from the PV using pvmove
Actual results:
# pvmove -v /dev/md5
    Wiping cache of LVM-capable devices
    Finding volume group "vol0"
    Archiving volume group "vol0" metadata (seqno 135).
    Creating logical volume pvmove0
  Skipping snapshot-related LV server1-template
  Skipping snapshot-related LV server1
  No data to move for vol0

server1-template is the origin LV, and server1 is the snapshot.

Expected results:
Data should be moved when I have a snapshot.
Comment 3 Mikuláš Patočka 2010-10-31 23:33:44 EDT
This isn't possible and safe given the architecture of userspace LVM2. Closing as WONTFIX.
Comment 4 Alasdair Kergon 2010-11-01 06:36:15 EDT
Why isn't it possible in your view?
Comment 5 Mikuláš Patočka 2010-11-01 07:22:42 EDT
The code is too complicated. Snapshots of mirrors are impossible to implement correctly and there may be similar problems here.

Also, it would be very hard to test --- you need to test pvmove at all stages versus all possible snapshot operations.
Comment 6 Mikuláš Patočka 2010-11-01 07:38:58 EDT
dmeventd isn't running in "pvmove" case, so the dmeventd-vs-lvm deadlock doesn't happen. But you must test background-lvm-vs-snapshot-operation, which is a different issue, but also complicated.

Example: what if the background thread moves "lv-real" device and meanwhile you remove the snapshot and the "lv-real" device disappers? Or the other way around, the background thread is moving "lv" and now you create a snapshot and it must not touch "lv" and move "lv-real" instead?

I think the coding effort to support this would be disproportionate to the utility. But maybe, if snapshots are going to be used for general storage, this feature would be needed.
Comment 7 Alasdair Kergon 2010-11-01 07:45:34 EDT
pvmove only uses an in-core log, not an on-disk one, so I think the known snapshot-of-mirror problems are irrelevant.

I don't see how stacking snapshots/origins above a pvmove is any different from stacking anything else above one.

The key point here is simply to support "something" stacked above a pvmove - concerns about 'snapshots' being especially tricky are a red herring I believe.  When the restriction was first added, the activation code could not handle stacking properly.  Now it can, so I still think this is a fairly simple feature to complete, albeit with low priority because this seems to be the only request we have had for it and it's not something lots of people are asking for.
Comment 8 Alasdair Kergon 2010-11-01 07:47:36 EDT
Interactions with snapshot merge should be covered adequately by locking - only one process manipulates metadata at once.  Each such manipulation only deals with one layer of the stack - what else is going on above or below should be irrelevant.
Comment 9 Alasdair Kergon 2010-11-01 07:51:54 EDT
The other defence we (already) use is locking (a flag) set on specific LVs inside the metadata while a pvmove operation is occurring, which stops other operations attempting to change the LV structure in ways that we can't handle at the same time.
Comment 10 Tru Huynh 2011-04-20 10:04:16 EDT
RFE: could you add some warning on the pvmove page such as:

"caveat: it's currently not possible to pvmove an physical volume containing
a snapshot"
Comment 13 RHEL Product and Program Management 2012-10-10 07:52:01 EDT
Thank you for submitting this issue for consideration. Red Hat Enterprise Linux 5 has reached the end of Production 1 Phase of its Life Cycle.  Red Hat does not plan to incorporate the suggested capability in a future Red Hat Enterprise Linux 5 minor release. If you would like Red  Hat to re-consider this feature request and the requested functionality is not currently in Red Hat Enterprise Linux 6, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.
Comment 14 roma1390 2012-10-10 08:02:15 EDT
this is related not only with Red Hat Enterprise Linux 5, this defect is can
be is brand new last one. Please update product field or there is recommended
to clone this bug?
Comment 15 Alasdair Kergon 2013-03-21 08:42:18 EDT
This remains a problem.  See also bug 734134
Comment 18 Jonathan Earl Brassow 2014-03-17 18:45:48 EDT
This should be available in the latest RHEL6 version in single machine mode.

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