linux-lvm.redhat.com archive mirror
 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 17:29:24 +0200	[thread overview]
Message-ID: <def626d9-52ef-4761-ebe0-3a29bd664bb1@gmail.com> (raw)
In-Reply-To: <909d4cae-ddd2-3951-eee8-8dec8faa6f22@redhat.com>

Thanks for feedback,


I know that thick LV snapshots are out dated, and that one should use 
thin LV snapshots.

But my understanding is that the dm- cow and dm - origin are still 
present and available in thin too?


Example of a scenario:

1. Create a snapshot of LV testlv with the name snaplv
2. Perform a full copy of the snaplv using for example dd to a block device
3. Delete the snapshot

Now I would like to re-attach this external block device as a snapshot 
again.

After all, it is just a dm and LVM config, right? So for example:

1. create a snapshot of testlv with the name snaplv
2. re create the -cow meta data device : 
<offset><chunk_size><data>...<offset><chunk_size><data><EOF>
 ��� Recreate this -cow meta data device by telling the origin that all 
data has been changed and are in the cow device (the raw device)
3. If the above were possible to perform, than it could be possible to 
instantly get at copy of the LV data using the lvconvert --merge command

I have already invented a way to perform "block level incremental 
forever"; using the -cow device.

And a possibility to reverse the blocks, to copy back only changed 
content from external devices.

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?

Regards Tomas


Den 2019-10-22 kl. 15:57, skrev Zdenek Kabelac:

> Dne 22. 10. 19 v 12:47 Dalebj�rk, Tomas napsal(a):
>> Hi
>>
>> When you create a snapshot of a logical volume.
>>
>> A new virtual dm- device will be created with the content of the 
>> changes from the origin.
>>
>> This cow device can than be used to read changed contents etc.
>>
>>
>> In case of an incident, this cow device can be used to read back the 
>> changed content to its origin using the "lvmerge" command.
>>
>>
>> The question I have is if there is a way to couple an external cow 
>> device to an empty equaly sized logical volume,
>>
>> so that the empty logical volume is aware of that all changed content 
>> are placed on this attached cow device?
>>
>> If that is possible, than it will help making instant recovery of LV 
>> volumes from an external source using native lvmerge command, from 
>> for example a backup server.
>
> For most info how old snapshot for so called 'thick' LVs works - check
> these papers: http://people.redhat.com/agk/talks/
>
>
> lvconvert --merge
>
> is in fact 'instant' operation - when it happens - you can immediately 
> access
> 'already merged' content� while the merge is happening in the background
> (you can look for copies percentage in lvs command)
>
>
> However 'thick' LVs with old snapshots are rather 'dated' technology
> you should probably checkout the usage of� thinly provisioned LVs.
>
> Regards
>
> Zdenek
>
>

  reply	other threads:[~2019-10-22 15:29 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 [this message]
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
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=def626d9-52ef-4761-ebe0-3a29bd664bb1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).