All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dalebjörk, Tomas" <tomas.dalebjork@gmail.com>
To: Zdenek Kabelac <zkabelac@redhat.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] exposing snapshot block device
Date: Tue, 22 Oct 2019 18:13:25 +0200	[thread overview]
Message-ID: <83c4026c-5abe-e9e5-ac1d-6ed9e025e660@gmail.com> (raw)
In-Reply-To: <f1f7dfc1-dfd8-a023-5305-2065446a890e@redhat.com>

That is cool,

But, are there any practical example how this could be working in reality.

Eg:

lvcreate -s mysnap vg/testlv

thin_dump vg/mysnap > deltafile # I assume that this should be the name 
of the snapshot?

But... How to recreate only the metadata only?, so that the meta data 
changes are associated to an external device?

thin_restore -i metadata < deltafile # that will restore the metadata, 
but I also want the restored meta data to point out the location of the 
data from for example a file or a raw deice


I have created a way to perform block level incremental forever by 
reading the -cow device, and thin_dump would be nice replacement for that.

This can also be reversed, so that the thin_restore can be used to 
restore the meta data and the data@same time (If I now the format of it)

But it would be much more better if one can do the restoration in 
background using "lvconvert --merge" tool, by first restoring the 
metadata (I can understand that this part is needed), and assoicate all 
the data to an external raw disk or much more better a file, so that all 
changes associated to this restored snapshot can be found on the file.


Not so good to explain this, but I hope you understand how I am thinking.

A destroyed thin pool, can than be restored instantly using a backup 
server as the cow similar device.

Regards Tomas

Den 2019-10-22 kl. 17:36, skrev Zdenek Kabelac:
> Dne 22. 10. 19 v 17:29 Dalebj�rk, Tomas napsal(a):
>> Thanks for feedback,
>>
>> But, it would be better if the cow device could be recreated in a 
>> faster way, mentioning that all blocks are present on an external 
>> device, so that the LV volume can be restored much quicker using 
>> "lvconvert --merge" command.
>>
>> That would be super cool!
>>
>> Imagine backing up multi terrabyte sized volumes in minutes to 
>> external destinations, and restoring the data in seconds using 
>> instant recovery by re-creating or emulating the cow device, and 
>> associating all blocks to an external device?
>>
>
> Hi
>
> I do not want to break your imagination here, but that is exactly the 
> thing you can do with thin provisioning and thin_delta tool.
>
> You just work with LV, take snapshot1, take snapshot2,
> send delta between� s1 -> s2� to remove machine,
> remove s1, take s3, send delta� s2 -> s3...
>
> It's just not automated by lvm2 ATM...
>
> Using this with old snapshot would be insanely inefficient...
>
> Regards
>
> Zdenek
>

  reply	other threads:[~2019-10-22 16:13 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 [this message]
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
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=83c4026c-5abe-e9e5-ac1d-6ed9e025e660@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.