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 859561 - clarification needed for a thinp snapshot inheriting the position of origin volume
Summary: clarification needed for a thinp snapshot inheriting the position of origin v...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Logical_Volume_Manager
Version: 6.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Steven J. Levine
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-21 20:47 UTC by Corey Marthaler
Modified: 2013-02-25 17:52 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-25 17:52:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Corey Marthaler 2012-09-21 20:47:48 UTC 
Description of problem:
In the documentation I see the following sentence about how a snapshot can be used as "the" new origin volume.

"Instead of merging a snapshot with the origin volume, a user may choose to 
delete the origin and start using its snapshot as the origin."

I may just be reading too much into this statement, and if so this bug can be closed, but is there some special way or command for this to happen? Or is it just that when a thinp snapshot's origin volume is deleted, all data is written out to each snapshot, and they each become "regular" volumes? 

I ask because if I have originA and snap1 and snap2, and I delete originA and start using snap1 as the new origin volume, does it become the new origin volume for snap2? Or just an origin volume for for any snapshots taken of it in the future? Testing shows that the later is true.

So...

1. Should the doc be changed to "and start using its snapshot as a new origin."?

2. Am I just being too pedantic with my misunderstanding?

3. Is there a special process or command that I'm missing that does just this? 




Version-Release number of selected component (if applicable):
2.6.32-279.el6.x86_64
lvm2-2.02.97-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
lvm2-libs-2.02.97-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
lvm2-cluster-2.02.97-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
udev-147-2.41.el6    BUILT: Thu Mar  1 13:01:08 CST 2012
device-mapper-1.02.76-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
device-mapper-libs-1.02.76-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
device-mapper-event-1.02.76-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
device-mapper-event-libs-1.02.76-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
cmirror-2.02.97-3.el6    BUILT: Tue Sep 11 05:06:56 CDT 2012
Comment 1 Zdenek Kabelac 2012-09-24 07:12:30 UTC 
There can be simple view over the thinpool functionality - all thin volumes may share chunks between multiple volumes - thus deleting 'originA' means - you decrease 'use-counter' for all chunks in the originA.
If no other volume shares some chunk - it returns as free back to the pool for new reallocation.  If the chunk is still being in-use by snap1 and snap2 - it can't be reused as it keeps 'life' data - and also there is no need for write/copy any data from origin to snapshot when you delete the origin - it's just 'metadata' operation.

Since it would be hard to 'maintain' some generic history tree (we are not database yet :)) - we decided to keep history simple - and once you delete the origin - all its thin snapshots becomes autonomous new thin-volumes - so they will be presented just like any other thin volume without any sign of being created as snapshot of some other thin volume origin.
Note You need to log in before you can comment on or make changes to this bug.