Bug 859561 - clarification needed for a thinp snapshot inheriting the position of origin volume
clarification needed for a thinp snapshot inheriting the position of origin v...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Logical_Volume_Manager (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Steven J. Levine
: Documentation
Depends On:
  Show dependency treegraph
Reported: 2012-09-21 16:47 EDT by Corey Marthaler
Modified: 2013-02-25 12:52 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-02-25 12:52:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2012-09-21 16:47:48 EDT
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.


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):
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 03:12:30 EDT
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.