Bug 814837 - Support migration of thin LVs between thin pools
Support migration of thin LVs between thin pools
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
Unspecified Linux
medium Severity medium
: ---
: ---
Assigned To: LVM and device-mapper development team
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-20 15:55 EDT by Alasdair Kergon
Modified: 2016-07-27 13:45 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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)

  None (edit)
Description Alasdair Kergon 2012-04-20 15:55:37 EDT
Various operations could involve the migration of LVs between pools.

lvconvert options / merge / split / clone etc.
Comment 1 Alasdair Kergon 2012-04-20 16:01:00 EDT
(includes 'normal' thin LVs and snapshots)
Comment 3 RHEL Product and Program Management 2012-07-10 04:25:21 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 4 RHEL Product and Program Management 2012-07-10 19:57:39 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 5 Corey Marthaler 2012-08-30 14:20:23 EDT
In an attempt to port all the snapshot test cases to work with thinp origins, I found that thinp snaps can not currently be merged, which appears to be the purpose of this bug.

[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)
  thin_snap    snapper_thinp Vwi-a-tz   1.00g POOL origin   0.00
  origin       snapper_thinp Vwi-a-tz   1.00g POOL          0.00

[root@taft-01 ~]# lvconvert --merge snapper_thinp/thin_snap
  "thin_snap" is not a mergeable logical volume
Comment 7 Zdenek Kabelac 2012-08-31 05:13:07 EDT
There is no merging of thin snapshots - i.e. you either delete  origin or snapshot - both are thin volumes which shares same blocks in the thin pool.

So unlike with old snaphost were blocks were copied from snapshot storage to replace blocks in origin LV with thin there is no reason for this operation.

I'm not sure whether we should maintain  'old-style' snapshot compatibility,
and implement  '--merge' as    removal of origin thin volume and its replacement with  thin snapshot volume via remapping dm tables -  there could be potentially some use case for this ?
Comment 8 Tom Lavigne 2012-09-07 11:22:01 EDT
This request was evaluated by Red Hat Product Management for 
inclusion in the current release of Red Hat Enterprise Linux.
Since we are unable to provide this feature at this time,  
it has been proposed for the next release of 
Red Hat Enterprise Linux.
Comment 10 Dusty Mabe 2014-06-18 11:27:13 EDT
Any chance of giving this additional consideration. I use thin LVs quite a bit (see http://dustymabe.com/category/lvm/) and would love to have a seamless rollback mechanism like there is available for old style snapshots; i.e after the lvconvert --merge command is run then everything, including device names, is back to the point at which the snapshot was taken. Now when I perform rollbacks I have to either rename devices manually or update all references to the old device. 

Thoughts? 

Dusty
Comment 11 Jonathan Earl Brassow 2014-07-24 21:03:14 EDT
(In reply to Zdenek Kabelac from comment #7)
> There is no merging of thin snapshots - i.e. you either delete  origin or
> snapshot - both are thin volumes which shares same blocks in the thin pool.
> 
> So unlike with old snaphost were blocks were copied from snapshot storage to
> replace blocks in origin LV with thin there is no reason for this operation.
> 
> I'm not sure whether we should maintain  'old-style' snapshot compatibility,
> and implement  '--merge' as    removal of origin thin volume and its
> replacement with  thin snapshot volume via remapping dm tables -  there
> could be potentially some use case for this ?

And so we did eventually implement a similarly working '--merge' for thin-snaps:

[root@bp-01 ~]# lvcreate -T -V 5G -n thin_lv vg/thinpool
  Logical volume "thin_lv" created
[root@bp-01 ~]# lvcreate -s -n thin_lv_snap vg/thin_lv
  Logical volume "thin_lv_snap" created
[root@bp-01 ~]# lvs vg
  LV           VG   Attr       LSize Pool     Origin  Data%  Meta%  Move Log Cpy%Sync Convert
  thin_lv      vg   Vwi-a-tz-- 5.00g thinpool         0.00                                   
  thin_lv_snap vg   Vwi---tz-k 5.00g thinpool thin_lv                                        
  thinpool     vg   twi-a-tz-- 1.00g                  0.00   0.36                            
[root@bp-01 ~]# lvconvert --merge vg/thin_lv_snap
[root@bp-01 ~]# lvs vg
  LV       VG   Attr       LSize Pool     Origin Data%  Meta%  Move Log Cpy%Sync Convert
  thin_lv  vg   Vwi-a-tz-- 5.00g thinpool        0.00                                   
  thinpool vg   twi-a-tz-- 1.00g                 0.00   0.36                            



... but this bug is not about merging, I don't think.  It was originally filed to explore the possibility of e.g. moving a thinLV from one thin-pool to another - a feature that is not on the near term priority list.
Comment 12 Jonathan Earl Brassow 2015-10-07 11:17:20 EDT
pushing this feature out to rawhide
Comment 13 Heinz Mauelshagen 2016-07-27 13:45:55 EDT
The upcoming RAID duplication feature (resynchronizing raid1 on top of arbitrary SubLVs such as thin) can duplicate thin LVs between thin pools but it'd do it suboptimal, because it'll mirror the whole thin LV from the source into the destination pool thus fully provisioning the destination thin LV.

One optimization would be that the thin target _optionally_ avoids provisioning blocks for zero write payloads (i.e. zero filled bios).

This'd still have the problem of all source thin LV blocks being read and written to the destination thin LV in raid1 resynchronization, which a thin mapping aware approach can avoid.

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