All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dalebjörk, Tomas" <tomas.dalebjork@gmail.com>
To: Zdenek Kabelac <zkabelac@redhat.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] exposing snapshot block device
Date: Tue, 8 Sep 2020 14:32:23 +0200	[thread overview]
Message-ID: <a729f619-56e6-b949-eaee-4719fcec33ef@gmail.com> (raw)
In-Reply-To: <643c43ad-0814-18a7-bb60-439adb4c6514@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4365 bytes --]

  reply	other threads:[~2020-09-08 12:32 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-22 10:47 [linux-lvm] exposing snapshot block device Dalebjörk, Tomas
2019-10-22 13:57 ` Zdenek Kabelac
2019-10-22 15:29   ` Dalebjörk, Tomas
2019-10-22 15:36     ` Zdenek Kabelac
2019-10-22 16:13       ` Dalebjörk, Tomas
2019-10-23 10:26         ` Zdenek Kabelac
2019-10-23 10:56           ` Tomas Dalebjörk
2019-10-22 16:15       ` Stuart D. Gathman
2019-10-22 17:02         ` Tomas Dalebjörk
2019-10-22 21:38         ` Gionatan Danti
2019-10-22 22:53           ` Stuart D. Gathman
2019-10-23  6:58             ` Gionatan Danti
2019-10-23 10:06               ` Tomas Dalebjörk
2019-10-23 10:12             ` Zdenek Kabelac
2019-10-23 10:46         ` Zdenek Kabelac
2019-10-23 11:08           ` Gionatan Danti
2019-10-23 11:24             ` Tomas Dalebjörk
2019-10-23 11:26               ` Tomas Dalebjörk
2019-10-24 16:01               ` Zdenek Kabelac
2019-10-25 16:31                 ` Tomas Dalebjörk
2019-11-04  5:54                   ` Tomas Dalebjörk
2019-11-04 10:07                     ` Zdenek Kabelac
2019-11-04 14:40                       ` Tomas Dalebjörk
2019-11-04 15:04                         ` Zdenek Kabelac
2019-11-04 17:28                           ` Tomas Dalebjörk
2019-11-05 16:24                             ` Zdenek Kabelac
2019-11-05 16:40                         ` Mikulas Patocka
2019-11-05 20:56                           ` Tomas Dalebjörk
2019-11-06  9:22                             ` Zdenek Kabelac
2019-11-07 16:54                             ` Mikulas Patocka
2019-11-07 17:29                               ` Tomas Dalebjörk
2020-09-04 12:09                                 ` Tomas Dalebjörk
2020-09-04 12:37                                   ` Zdenek Kabelac
2020-09-07 13:09                                   ` Mikulas Patocka
2020-09-07 14:14                                     ` Dalebjörk, Tomas
2020-09-07 14:17                                       ` Zdenek Kabelac
2020-09-07 16:34                                         ` Tomas Dalebjörk
2020-09-07 16:42                                           ` Zdenek Kabelac
2020-09-07 17:37                                             ` Tomas Dalebjörk
2020-09-07 17:50                                               ` Zdenek Kabelac
2020-09-08 12:32                                                 ` Dalebjörk, Tomas [this message]
2020-09-07 19:56                                             ` Tomas Dalebjörk
2020-09-07 20:22                                               ` Tomas Dalebjörk
2020-09-07 21:02                                               ` Tomas Dalebjörk
2019-10-23 12:12             ` Ilia Zykov
2019-10-23 12:20             ` Ilia Zykov
2019-10-23 13:05               ` Zdenek Kabelac
2019-10-23 14:40                 ` Gionatan Danti
2019-10-23 15:46                   ` Ilia Zykov
2019-10-23 12:59             ` Zdenek Kabelac
2019-10-23 14:37               ` Gionatan Danti
2019-10-23 15:37                 ` Zdenek Kabelac
2019-10-23 17:16                   ` Gionatan Danti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a729f619-56e6-b949-eaee-4719fcec33ef@gmail.com \
    --to=tomas.dalebjork@gmail.com \
    --cc=linux-lvm@redhat.com \
    --cc=zkabelac@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.