linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	"Stuart D. Gathman" <stuart@gathman.org>
Cc: "Dalebjörk, Tomas" <tomas.dalebjork@gmail.com>
Subject: Re: [linux-lvm] exposing snapshot block device
Date: Wed, 23 Oct 2019 12:46:23 +0200	[thread overview]
Message-ID: <f3a53c24-1f91-e5f5-e7e1-091b886da44a@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.21.1910221142290.1156@fairfax.gathman.org>

Dne 22. 10. 19 v 18:15 Stuart D. Gathman napsal(a):
> On Tue, 22 Oct 2019, Zdenek Kabelac wrote:
> 
>> Dne 22. 10. 19 v 17:29 Dalebj�rk, Tomas napsal(a):
>>> 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.
> 
>> 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.
> 
> lvconvert --merge does a "rollback" to the point at which the snapshot
> was taken.� The master LV already has current data.� What Tomas wants to
> be able to do a "rollforward" from the point at which the snapshot was
> taken.� He also wants to be able to put the cow volume on an
> extern/remote medium, and add a snapshot using an already existing cow.
> 
> This way, restoring means copying the full volume from backup, creating
> a snapshot using existing external cow, then lvconvert --merge instantly 
> logically applies the cow changes while updating the master
> LV.
> 
> Pros:
> 
> "Old" snapshots are exactly as efficient as thin when there is exactly
> one.� They only get inefficient with multiple snapshots.� On the other
> hand, thin volumes are as inefficient as an old LV with one snapshot.
> An old LV is as efficient, and as anti-fragile, as a partition.� Thin
> volumes are much more flexible, but depend on much more fragile database
> like meta-data.


Just few 'comments' - it's not really comparable - the efficiency of thin-pool 
metadata outperforms old snapshot in BIG way (there is no point to talk about 
snapshots that takes just couple of MiB)

There is also BIG difference about the usage of old snapshot origin and snapshot.

COW of old snapshot effectively cuts performance 1/2 if you write to origin.

> For this reason, I always prefer "old" LVs when the functionality of
> thin LVs are not actually needed.� I can even manually recover from
> trashed meta data by editing it, as it is human readable text.

On the other hand you can loose  COW snapshot at any moment in time
if your 'COW' storage is no big enough - this is very different
from thin-poo.....

Regards

Zdenek

  parent reply	other threads:[~2019-10-23 10:46 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 [this message]
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=f3a53c24-1f91-e5f5-e7e1-091b886da44a@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=stuart@gathman.org \
    --cc=tomas.dalebjork@gmail.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).