Bug 859561

Summary:	clarification needed for a thinp snapshot inheriting the position of origin volume
Product:	Red Hat Enterprise Linux 6	Reporter:	Corey Marthaler <cmarthal>
Component:	doc-Logical_Volume_Manager	Assignee:	Steven J. Levine <slevine>
Status:	CLOSED CURRENTRELEASE	QA Contact:	ecs-bugs
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.3	CC:	agk, coughlan, dwysocha, heinzm, jbrassow, jha, jskeoch, mbroz, msnitzer, prajnoha, prockai, thornber, zkabelac
Target Milestone:	rc	Keywords:	Documentation
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-25 17:52:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.