Various operations could involve the migration of LVs between pools. lvconvert options / merge / split / clone etc.
(includes 'normal' thin LVs and snapshots)
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.
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.
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
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 ?
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.
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
(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.
pushing this feature out to rawhide
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.
(In reply to Jonathan Earl Brassow from comment #11) > (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. We are not going to implement moving thinLVs from one pool to another, and the secondary issue is solved. Closing.