RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 474650 - Cannot move data using pvmove if the PV has a snapshot or mirror
Summary: Cannot move data using pvmove if the PV has a snapshot or mirror
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Jonathan Earl Brassow
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 806907 1056252
TreeView+ depends on / blocked
 
Reported: 2008-12-04 19:03 UTC by Forrest Taylor
Modified: 2018-12-03 17:05 UTC (History)
17 users (show)

Fixed In Version: lvm2-2.02.100-8.el6.x86_64
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-18 09:05:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 309723 0 None None None Never

Description Forrest Taylor 2008-12-04 19:03:10 UTC 
Description of problem:
pvmove does not move data that is included in a snapshot.


Version-Release number of selected component (if applicable):
lvm2-2.02.32-4.el5

How reproducible:
Always

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-11-01 03:33:44 UTC 
This isn't possible and safe given the architecture of userspace LVM2. Closing as WONTFIX.
Comment 4 Alasdair Kergon 2010-11-01 10:36:15 UTC 
Why isn't it possible in your view?
Comment 5 Mikuláš Patočka 2010-11-01 11:22:42 UTC 
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 11:38:58 UTC 
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 11:45:34 UTC 
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 11:47:36 UTC 
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 11:51:54 UTC 
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 14:04:16 UTC 
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"
Thanks
Comment 13 RHEL Program Management 2012-10-10 11:52:01 UTC 
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 12:02:15 UTC 
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 12:42:18 UTC 
This remains a problem.  See also bug 734134
Comment 18 Jonathan Earl Brassow 2014-03-17 22:45:48 UTC 
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.