From: Zdenek Kabelac <zkabelac@redhat.com>
To: "Davis, Matthew" <Matthew.Davis.2@team.telstra.com>,
LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] how to copy a snapshot, or restore snapshot without deleting it
Date: Thu, 17 Jan 2019 10:21:55 +0100 [thread overview]
Message-ID: <690f7e10-f146-202f-56b2-2e245bcc001b@redhat.com> (raw)
In-Reply-To: <SYBPR01MB3931927F2E7B62070F84C040C2830@SYBPR01MB3931.ausprd01.prod.outlook.com>
Dne 17. 01. 19 v 2:12 Davis, Matthew napsal(a):
> Hi Zdenek,
>
> What do you mean "it's origin is already gone"?
Hi
Your field 'Origin' in your 'lvs -a' was empty - so the actual origin used for
taking 'fresh' LV snapshot is simply no longer existing.
lvm2 is (ATM) not a database tool trying to resolve/guess what can or cannot
be still considered as the origin - so i.e. if you take multiple snapshots of
a single origin and then you merge one snapshot back to origin - 'the
original origin' used for all other snapshots is 'gone' - as lvm2 is not
resolving here the history and relation of data content whether the meaning of
origin still applies.
What can make sense in your case is to extend probably 'lvconvert' logic and
provide operation i.e. --replace - which would be working mostly like merge
- but with thins you would be able to specify which thinLV should replace
some other thinLV so basically specifying replace LV1 with LV2 - which you can
do by lvremove + lvrename ATM - but I can see usefulness for supporting this
for i.e. root LV which is typically in-use all the time.
I'm not seeing possible to extended the internal logic in lvm2 that would be
deciding which NEW origin should be replacing removed/merged origin in all
related snapshots - I'm pretty sure every user would expect a different one...
Zdenek
next prev parent reply other threads:[~2019-01-17 9:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-03 4:46 [linux-lvm] how to copy a snapshot, or restore snapshot without deleting it Davis, Matthew
2019-01-03 9:32 ` Tomas Dalebjörk
2019-01-03 14:09 ` Marian Csontos
2019-01-10 6:23 ` Davis, Matthew
2019-01-10 9:45 ` Zdenek Kabelac
2019-01-14 22:44 ` Davis, Matthew
2019-01-15 10:49 ` Zdenek Kabelac
2019-01-15 23:03 ` Davis, Matthew
2019-01-16 13:55 ` Zdenek Kabelac
2019-01-17 1:12 ` Davis, Matthew
2019-01-17 9:21 ` Zdenek Kabelac [this message]
2019-01-18 0:53 ` Davis, Matthew
2019-01-18 9:34 ` Zdenek Kabelac
2019-01-21 10:32 ` Zdenek Kabelac
2019-01-28 11:49 ` Zdenek Kabelac
2019-01-30 23:58 ` Davis, Matthew
2019-01-10 14:34 ` Tomas Dalebjörk
2019-01-11 19:29 ` Sarah Newman
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=690f7e10-f146-202f-56b2-2e245bcc001b@redhat.com \
--to=zkabelac@redhat.com \
--cc=Matthew.Davis.2@team.telstra.com \
--cc=linux-lvm@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).