From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 53D27A37A3 for ; Tue, 8 Sep 2020 12:32:33 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2F1C6906383 for ; Tue, 8 Sep 2020 12:32:33 +0000 (UTC) References: <4081c11e-d2b0-ebfa-d1a0-92a4efc79e81@redhat.com> <643c43ad-0814-18a7-bb60-439adb4c6514@redhat.com> From: =?UTF-8?Q?Dalebj=c3=b6rk=2c_Tomas?= Message-ID: Date: Tue, 8 Sep 2020 14:32:23 +0200 MIME-Version: 1.0 In-Reply-To: <643c43ad-0814-18a7-bb60-439adb4c6514@redhat.com> Content-Type: multipart/alternative; boundary="------------5658DE6AE8A38C07BC45B845" Content-Language: sv Subject: Re: [linux-lvm] exposing snapshot block device Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: To: Zdenek Kabelac Cc: LVM general discussion and development This is a multi-part message in MIME format. --------------5658DE6AE8A38C07BC45B845 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Hi, This is the steps that I did. - the COW data exists on /dev/loop1, including space for the PV header + metadata I created a fakevg template file from vgcfgbackup /tmp/fakevg.bkp ( the content of this file I created fake uuid etc... ) I craete a fake uuid for the PV # pvcreate -ff -u fake-uidx-nrxx-xxxx --restorefile /tmp/fakevg.bkp And created rhe metadata from the backup # vgcfgrestore -f /tmp/fakevg.bkp fakevg I can now see the lvsnap in fakevg Perhaps the restore can be done directly to the destination vg? not sure... Anyhow, I than used the vgsplit to move the fakevg data to the destination vg # vgsplit fakevg destvg /dev/loop1 I know have the lvsnap volume in the correct volume group From here, I connected the lvsnap to a lv destination using # lvconvert -Zn -s destvg/lvsnap destvg/destlv I know have a snapshot connected to the origin destlv From here, I can either mount the snapshot and start using it, or revert to the snapshot # lvchange -a n destvg/destlv # lvconvert --merge -b destvg/lvsnap # lvchange -a y destvg/destlv Now to my questions... is there any DBUS api that can perform the vgcfgrestore operations that I can use through C? or another ways to recreate the metadata? I have to now use two steps: pvcreate + vgcfgrestore, where I just need to actually restore just the metadata (only vgcfgrestore)? If I run vgcfgrestore without pvcreate, than vgcfgrestore will not find the pvid, and cant be executed with a parameter like: # vgcfgrestore -f vgXX.bkp /dev/nbd Instead it has to be used with the parameter vgXX pointing out the volume group... I can live with vgcfgrestore + pvcreate, but would prefer to use the libblockdev (DBUS) or another api from C directly. What options do I have? Thanks for an excellent help God Bless Tomas Den 2020-09-07 kl. 19:50, skrev Zdenek Kabelac: > Dne 07. 09. 20 v 19:37 Tomas Dalebjörk napsal(a): >> thanks >> >> ok >>   vgsplit/merge instead >> and after that lvconvert-s >> >> yes, I am aware of the issues with corruption >> but if the cow device has all data, than no corruption will happen, >> right? >> >> if COW has a copy of all blocks >> than a lvconvert —merge, or mount of the snapshot volume will be >> without issues > > If the 'COW' has all the data - why do you need then snapshot ? > Why not travel whole LV instead of snapshot ? > > Also - nowdays this old (so called 'thick') snapshot is really slow > compared with thin-provisioning - might be good if you check what kind > of features > you can gain/loose if you would have switched to thin-pool > (clearly whole thin-pool (both data & metadata) would need to travel > between your VGs.) > > Regards > > Zdenek > --------------5658DE6AE8A38C07BC45B845 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi,


This is the steps that I did.

- the COW data exists on /dev/loop1, including space for the PV header + metadata

I created a fakevg template file from vgcfgbackup /tmp/fakevg.bkp

( the content of this file I created fake uuid etc... )


I craete a fake uuid for the PV

# pvcreate -ff -u fake-uidx-nrxx-xxxx --restorefile /tmp/fakevg.bkp


And created rhe metadata from the backup

# vgcfgrestore -f /tmp/fakevg.bkp fakevg


I can now see the lvsnap in fakevg

Perhaps the restore can be done directly to the destination vg? not sure...

Anyhow, I than used the vgsplit to move the fakevg data to the destination vg

# vgsplit fakevg destvg /dev/loop1


I know have the lvsnap volume in the correct volume group

From here, I connected the lvsnap to a lv destination using

# lvconvert -Zn -s destvg/lvsnap destvg/destlv


I know have a snapshot connected to the origin destlv

From here, I can either mount the snapshot and start using it, or revert to the snapshot

# lvchange -a n destvg/destlv
# lvconvert --merge -b destvg/lvsnap
# lvchange -a y destvg/destlv


Now to my questions...

is there any DBUS api that can perform the vgcfgrestore operations that I can use through C?

or another ways to recreate the metadata?

I have to now use two steps: pvcreate + vgcfgrestore, where I just need to actually restore just the metadata (only vgcfgrestore)?

If I run vgcfgrestore without pvcreate, than vgcfgrestore will not find the pvid, and cant be executed with a parameter like:

# vgcfgrestore -f vgXX.bkp /dev/nbd

Instead it has to be used with the parameter vgXX pointing out the volume group...


I can live with vgcfgrestore + pvcreate, but would prefer to use the libblockdev (DBUS) or another api from C directly.

What options do I have?


Thanks for an excellent help

God Bless

Tomas



Den 2020-09-07 kl. 19:50, skrev Zdenek Kabelac:
Dne 07. 09. 20 v 19:37 Tomas Dalebjörk napsal(a):
thanks

ok
  vgsplit/merge instead
and after that lvconvert-s

yes, I am aware of the issues with corruption
but if the cow device has all data, than no corruption will happen, right?

if COW has a copy of all blocks
than a lvconvert —merge, or mount of the snapshot volume will be without issues

If the 'COW' has all the data - why do you need then snapshot ?
Why not travel whole LV instead of snapshot ?

Also - nowdays this old (so called 'thick') snapshot is really slow compared with thin-provisioning - might be good if you check what kind of features
you can gain/loose if you would have switched to thin-pool
(clearly whole thin-pool (both data & metadata) would need to travel between your VGs.)

Regards

Zdenek

--------------5658DE6AE8A38C07BC45B845--