Bug 474650
| Summary: | Cannot move data using pvmove if the PV has a snapshot or mirror | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Forrest Taylor <ftaylor> |
| Component: | lvm2 | Assignee: | Jonathan Earl Brassow <jbrassow> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.0 | CC: | agk, amos.shapira, bmarzins, dwysocha, heinzm, iannis, jbrassow, jentrena, mpatocka, msnitzer, ndevos, pasteur, prajnoha, prockai, roma1390, thornber, zkabelac |
| Target Milestone: | pre-dev-freeze | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.100-8.el6.x86_64 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-18 09:05:06 UTC | Type: | --- |
| 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: | 806907, 1056252 | ||
This isn't possible and safe given the architecture of userspace LVM2. Closing as WONTFIX. Why isn't it possible in your view? 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. 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. 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. 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. 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. 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 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. 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? This remains a problem. See also bug 734134 This should be available in the latest RHEL6 version in single machine mode. |
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.