Bug 853259

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)

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?

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

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.

(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.

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.

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.

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).

Created attachment 997800 [details]
Patch for process_each_lv_in_vg

Created attachment 1002291 [details]
Patch for process_each_lv_in_vg

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.

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)

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