[linux-lvm] exposing snapshot block device

Dalebjörk, Tomas tomas.dalebjork at gmail.com
Tue Sep 8 12:32:23 UTC 2020


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20200908/450e6565/attachment.htm>


More information about the linux-lvm mailing list