Bug 853259 - removal of a thinp origin volume doesn't remove it's corresponding snapshot vol
removal of a thinp origin volume doesn't remove it's corresponding snapshot vol
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.3
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Peter Rajnoha
cluster-qe@redhat.com
Steven J. Levine
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-30 17:24 EDT by Corey Marthaler
Modified: 2015-07-22 03:36 EDT (History)
13 users (show)

See Also:
Fixed In Version: lvm2-2.02.118-1.el6
Doc Type: Enhancement
Doc Text:
Improved LVM entity management LVM now provides the -S/--select option, which allows users to process LVM entities based on specified selection criteria. This support is provided in all of the following commands: pv/vg/lvchange, vg/lvremove, vgexport/import, and pv/vg/lvdisplay (if used without the -C option). For further information on LVM selection criteria, see the "LVM Selection Criteria" appendix in Logical Volume Manager Administration: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/index.html
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 03:36:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for process_each_lv_in_vg (3.69 KB, text/plain)
2015-03-03 10:53 EST, Peter Rajnoha
no flags Details
Patch for process_each_lv_in_vg (3.69 KB, patch)
2015-03-04 04:55 EST, Peter Rajnoha
no flags Details | Diff
Patch for process_each_lv_in_vg (3.69 KB, patch)
2015-03-16 10:25 EDT, Peter Rajnoha
no flags Details | Diff

  None (edit)
Description Corey Marthaler 2012-08-30 17:24:33 EDT
Description of problem:
When removing a normal origin volume, it's snapshot volume is also removed. This is not the case when removing thinp origin volumes. 

I know this wasn't always the case with normal snapshot volumes as I've had to change this test case based on lvm behavior changes in the past.

So, is this expected with thinp origins?


# NORMAL SNAP
[root@taft-01 ~]# lvs -a -o +devices
  LV                       VG        Attr     LSize   Pool Origin Data%  Devices         
  origin                   snapper   owi-a-s- 300.00m                    /dev/sdh1(0)            
  remove_origin_under_snap snapper   swi-a-s- 100.00m      origin   0.00 /dev/sdh1(75)           
[root@taft-01 ~]# lvremove -f /dev/snapper/origin
  Logical volume "remove_origin_under_snap" successfully removed
  Logical volume "origin" successfully removed
[root@taft-01 ~]# lvs -a -o +devices
  LV      VG        Attr     LSize  Pool Origin Data%  Devices         


# THINP SNAP
[root@taft-01 ~]# lvs -a -o +devices
  LV                       VG            Attr     LSize   Pool Origin Data%  Devices         
  POOL                     snapper_thinp twi-a-tz 300.00m               0.00 POOL_tdata(0)
  [POOL_tdata]             snapper_thinp Twi-aot- 300.00m                    /dev/sdh1(0)
  [POOL_tmeta]             snapper_thinp ewi-aot-   4.00m                    /dev/sdg1(0)
  origin                   snapper_thinp Vwi-a-tz   1.00g POOL          0.00 
  remove_origin_under_snap snapper_thinp Vwi-a-tz   1.00g POOL origin   0.00
[root@taft-01 ~]# lvremove -f /dev/snapper_thinp/origin
  Logical volume "origin" successfully removed
[root@taft-01 ~]# lvs -a -o +devices
  LV                       VG            Attr     LSize   Pool Origin Data%  Devices         
  POOL                     snapper_thinp twi-a-tz 300.00m               0.00 POOL_tdata(0)
  [POOL_tdata]             snapper_thinp Twi-aot- 300.00m                    /dev/sdh1(0)
  [POOL_tmeta]             snapper_thinp ewi-aot-   4.00m                    /dev/sdg1(0)
  remove_origin_under_snap snapper_thinp Vwi-a-tz   1.00g POOL          0.00 


Version-Release number of selected component (if applicable):
2.6.32-279.el6.x86_64

lvm2-2.02.95-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
lvm2-libs-2.02.95-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
lvm2-cluster-2.02.95-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
udev-147-2.41.el6    BUILT: Thu Mar  1 13:01:08 CST 2012
device-mapper-1.02.74-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
device-mapper-libs-1.02.74-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
device-mapper-event-1.02.74-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
device-mapper-event-libs-1.02.74-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
cmirror-2.02.95-10.el6    BUILT: Fri May 18 03:26:00 CDT 2012
Comment 1 Zdenek Kabelac 2012-08-31 05:21:02 EDT
Thin snapshots are independent thin volumes which just share blocks in thin pool.
Thus thin snaps do not need to be even activated (unlike with old snaps, where origin and all its snaps must have been alive)

We may need to add some 'option' to remove  origin and all its snapshots?

Or and easy way - to add question when removing an thin 'origin' volume, whether the user wants to remove also it's related thin snapshots (since this information is being kept in lvm metadata)
Comment 2 Marian Csontos 2012-09-04 05:32:42 EDT
Let's suppose situation where:
1. there is orig -> orig_1 -> orig_1_1 (Notation: "a -> b" means "b is a snapshot of a")
2. remove the orig_1 without its snapshots

Few questions:
1. What will now happen when removing origin including snapshots - shall orig_1_1 be considered snapshot of orig or not?

2. Should that be configurable e.g. using extra option `--reparent`?

3. Should there be a way to change/erase link to snapshots' parent without deleting the parent e.g. using lvchange?

Offering an option to change the parent link may be enough if recursive behavior is chosen as default. Also this would allow to keep some snapshots while deleting others.

NOTE: `-R|--recursive` may be a good option name consitent with other tools. Should there be a `--no-recursive` option as well, e.g. if recursive behavior can be configured in lvm.conf?
Comment 3 Corey Marthaler 2012-09-04 16:09:41 EDT
This brings me to my next question: If a thinp origin is deactivated, its snaps will probably not be auto deactivated either correct? And are probably not supposed to be? 

If so, I'll have to change this test case as well.


SCENARIO - [create_snap_then_deactivate_origin]
Create snapshot, deactivate origin, check for leftover devfs entries
Making origin volume
Creating thinpool and corresponding thin origin volume
lvcreate --thinpool POOL -L 300M snapper_thinp
lvcreate --virtualsize 1G --thinpool snapper_thinp/POOL -n origin
Creating snap of origin
lvcreate -s /dev/snapper_thinp/origin -n snap_then_deactivate_origin
Deactivating origin/snap volume(s)
lvchange -an snapper_thinp/origin
all entries for snapshot weren't removed from devfs
Comment 7 Alasdair Kergon 2014-06-16 20:59:04 EDT
The 'natural' behaviour when asked to remove a volume is to remove only the volume requested.

With old-style snapshots, the origin and all it snapshots had to be removed together for correctness.

With thin snapshots that constraint no longer applies.  Removing the origin should NOT remove its snapshots by default.

Then the question is "If someone wants to remove a thin origin $LV in volume group $VG together with all its snapshots, how do they do that?"

In RHEL 6.6 the answer is:

lvremove `lvs --select name=$LV#origin=$LV --noheadings -o vg_name,lv_name --separator / $VG`

By RHEL 6.7, we think this will have become:

lvremove --select name=$LV#origin=$LV $VG

This is interpreted as:
Remove all the logical volumes in volume group $VG that are either named $LV or are snapshots with an origin named $LV.
Comment 10 Peter Rajnoha 2015-03-02 10:10:41 EST
(In reply to Alasdair Kergon from comment #7)
> lvremove `lvs --select name=$LV#origin=$LV --noheadings -o vg_name,lv_name
> --separator / $VG`

There's still one thing that needs to be handled here:

 - we're removing the origin as well as all its snapshots

 - lvremove iterates over the list of LVs and checks selection criteria against each LV that is processed

 - if we remove the origin LV first from the list, then the (original) snapshots no longer reference the origin LV (which are about to be processed next)

So currently, if we do "lvremove --select 'lv_name=lv1 || origin=lv1" where lv1 is thin origin, we end up with lv1 removed only if that's the one processed before any other snapshots.
Comment 11 Peter Rajnoha 2015-03-02 10:18:04 EST
Still, there's a possibility of transitive dependencies like:

  A --> B --> C

When using simple lvremove --select 'lv_name=A || origin=A', we'd end up with A and B removed, not C (which should or shouldn't be removed - depends on what user wants). So this needs more finishing. Also related to bug #1163895.
Comment 12 Peter Rajnoha 2015-03-02 10:20:59 EST
For 6.7, we can provide direct dependency only (but thing mentioned in comment #10 needs to be resolved for that still). And 6.8+ for full transitive dependency tree like the one mentioned in comment #11.
Comment 13 Peter Rajnoha 2015-03-03 10:53:21 EST
Created attachment 997572 [details]
Patch for process_each_lv_in_vg

(In reply to Peter Rajnoha from comment #12)
> For 6.7, we can provide direct dependency only (but thing mentioned in
> comment #10 needs to be resolved for that still).

Patch attached (I still need to test it a bit more, but test suite is passing with that so far) - that patch gathers list of LVs to process first and then does the processing itself (also tries to fix one FIXME I found in that code which is related).
Comment 14 Peter Rajnoha 2015-03-04 04:55:56 EST
Created attachment 997800 [details]
Patch for process_each_lv_in_vg
Comment 16 Peter Rajnoha 2015-03-16 10:25:51 EDT
Created attachment 1002291 [details]
Patch for process_each_lv_in_vg
Comment 17 Peter Rajnoha 2015-03-24 03:47:02 EDT
Patches are upstream now (slightly modified):

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=c9f021de0b4d2c873ef5b97d17c602d0380359fd
https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=8759f7d755cec7286d1bccda3a323b12481d5738

So, for this exact bug report where thins snapshots and origins are considered, one can use:

  lvremove --select 'lv_name=origin_lv_name || origin=origin_lv_name'

..to remove both thin origin and snapshots at the same time.
Comment 19 Corey Marthaler 2015-03-27 16:43:11 EDT
Marking this "feature" verifed in the latest rpms.

Using the --select option like mentioned in comment #17, you can remove the origin and any one level deep thin snapshots. I also added to our snap of snaps test case to deal with the chain of thin snaps and verifying I/O when links in the chain are removed like mentioned in comment #11.


2.6.32-546.el6.x86_64
lvm2-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
lvm2-libs-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
lvm2-cluster-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
udev-147-2.61.el6    BUILT: Mon Mar  2 05:08:11 CST 2015
device-mapper-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-libs-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-event-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-event-libs-1.02.95-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015
device-mapper-persistent-data-0.3.2-1.el6    BUILT: Fri Apr  4 08:43:06 CDT 2014
cmirror-2.02.118-1.el6    BUILT: Tue Mar 24 08:25:21 CDT 2015


[root@host-128 ~]# lvs -a -o +devices
  LV                     Attr       LSize   Pool Origin Data%  Meta% Devices
  POOL                   twi-aot---   1.00g             0.29   1.46  POOL_tdata(0)
  [POOL_tdata]           Twi-ao----   1.00g                          /dev/sda1(1)
  [POOL_tmeta]           ewi-ao----   4.00m                          /dev/sdb1(0)
  corresponding_snaps_1  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_10 Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_2  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_3  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_4  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_5  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_6  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_7  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_8  Vwi-a-t--k   1.00g POOL origin 0.05
  corresponding_snaps_9  Vwi-a-t--k   1.00g POOL origin 0.05
  [lvol0_pmspare]        ewi-------   4.00m                          /dev/sda1(0)
  origin                 Vwi-a-t---   1.00g POOL        0.05
[root@host-128 ~]# lvremove --yes --select 'lv_name=origin || origin=origin'
  Logical volume "origin" successfully removed
  Logical volume "corresponding_snaps_1" successfully removed
  Logical volume "corresponding_snaps_2" successfully removed
  Logical volume "corresponding_snaps_3" successfully removed
  Logical volume "corresponding_snaps_4" successfully removed
  Logical volume "corresponding_snaps_5" successfully removed
  Logical volume "corresponding_snaps_6" successfully removed
  Logical volume "corresponding_snaps_7" successfully removed
  Logical volume "corresponding_snaps_8" successfully removed
  Logical volume "corresponding_snaps_9" successfully removed
  Logical volume "corresponding_snaps_10" successfully removed
[root@host-128 ~]# lvs -a -o +devices
  LV              Attr       LSize   Pool Origin Data%  Meta% Devices
  POOL            twi-aot---   1.00g             0.24   1.37  POOL_tdata(0)
  [POOL_tdata]    Twi-ao----   1.00g                          /dev/sda1(1)
  [POOL_tmeta]    ewi-ao----   4.00m                          /dev/sdb1(0)
  [lvol0_pmspare] ewi-------   4.00m                          /dev/sda1(0)
Comment 20 errata-xmlrpc 2015-07-22 03:36:52 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1411.html

Note You need to log in before you can comment on or make changes to this bug.