All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: "Alexander Patrakov" <patrakov@gmail.com>,
	"Георгий Бажуков" <g.bazhukov@ideco.ru>
Subject: Re: [linux-lvm] LVM and chain of snapshots
Date: Wed, 20 Jan 2016 15:20:25 +0100	[thread overview]
Message-ID: <569F97A9.6050003@redhat.com> (raw)
In-Reply-To: <CAEmTpZGM6SPnBavLPD48rgMPGZ_Q8oPxo4v9kgge7Ae5AS6X+A@mail.gmail.com>

Dne 20.1.2016 v 13:54 Марк Коренберг napsal(a):
>
> 2016-01-20 17:09 GMT+05:00 Zdenek Kabelac <zkabelac@redhat.com
> <mailto:zkabelac@redhat.com>>:
>
>     ed sta
>
>
>
> Thanks for the response, but I do not understand how thin-provisioning is
> related to question i'm asking.
>
> As far as I understand, if 20 snapshots are created even in thin-provisioning
> mode, write to origin will be converted
> to 21 writes. Does not it ? My scenario mean that no write multiplication
> occurs while making "normal" operations in
> userspace (i.e. not writing to snapshots, while origin is under heavy
> write-load). Also, my scenario adds functionality
> of "snapshot of snapshot" easily. The case I'm trying to discuss is something
> like chain of qcow2 files used to make
> live snapshots in KVM.
>

You cannot chain old-snaps this way (you cannot map old-snap over old-snap)
And no - it's not easy to  add one.
So your proposal would have worked for exactly 1 level
e.g.  you continue to write to snap - and you keep origin intact,
but you cannot map another 'snap' over this snap.

lvm2 is currently incapable of doing this - and it's fairly nontrivial to 
support this - and especially when we have thin-provisioning, noone is 
currently planning to extend old snapshot with such complicated feature.

> Use case: having such snapshot every day. And after snapshot count exceed 30,
> meld first snapshot into it's origin.

So you would need 30 chained snaps....
And after 30 of them - you actually would need merging them - quite complicated...

> This operation should be possible without any unmounting. After merging, that
> snapshot should contain empty diff
> and so may be eliminated from chain via replacing dmsetup tables.

It's much better to directly update 'origin' and just drop no longer needed 
snapshot.

The only major issue is - running  30 old snapshot it just not suitable for 
any use...

> In other words, my proposal is not connected to low-level things in LVM. Yes,
> all snapshots I describe can be
> thin-provisioned. Just minimal logic, CLI and XML should extended.

In other words - you just described how thin-provisioning works
and there is no reason to reinvent the wheel again :)

So please for this use-case switch to thin-provisioning.

Regards

Zdenek

  reply	other threads:[~2016-01-20 14:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20 10:37 [linux-lvm] LVM and chain of snapshots Марк Коренберг
2016-01-20 12:09 ` Zdenek Kabelac
2016-01-20 12:54   ` Марк Коренберг
2016-01-20 14:20     ` Zdenek Kabelac [this message]
2016-01-20 13:02   ` Alexander E. Patrakov
2016-01-20 13:11     ` Zdenek Kabelac

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=569F97A9.6050003@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=g.bazhukov@ideco.ru \
    --cc=linux-lvm@redhat.com \
    --cc=patrakov@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 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.