archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <>
To: "Davis, Matthew" <>,
	LVM general discussion and development <>
Subject: Re: [linux-lvm] how to copy a snapshot, or restore snapshot without deleting it
Date: Fri, 18 Jan 2019 10:34:55 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Dne 18. 01. 19 v 1:53 Davis, Matthew napsal(a):
> Hi Zdenek,
> I assumed that LVM thin snapshots would work like git branches.
> Since git also uses diffs on the backend, and git is popular with developers, the same kind of behaviour seems reasonable to me.
> e.g.
> ```
> git checkout master
> git branch branchA # equivalent to creating snapshotA
> echo "modify" > file.txt # modify origin
> git checkout branchA ; git branch branchB # copy snapshotA to snapshotB
> git checkout master ; git merge branchA # restore snapshotA
> git branch # snapshotB still exists
> echo "modify2" > file.txt # modify origin
> git checkout branchB # restoring snapshot to root
> ```
> Oh well. It doesn't matter too much, since I've figured out how to get it to work. I just need to restore the oldest snapshot each time. Then LVM updates the origin accordingly.


As already said lvm2 is NOT DB engine, but let's look on it this way:

OriginLV ->  snap1

hour later

OriginLV ->  snap2

hour later

OriginLV ->  snap3

hour later

OriginLV ->  snap4

- then you decide to merge  snap2 into  OriginLV

So now there is *THE* question - whether snap2 can be now seen as origin for 
'snap1',  'snap3',  'snap4' ?

The user might have used and update all volumes meanwhile in some way.

After long discussion - we concluded it's hard question and we decided to drop 
  the connection for now.

There is some possibility to analyze what is the relation between all the 
orphans snaps - but it's quite a lot of work - and not directly related to 
volume management.

And I also want to point out you cannot really compare this with 'git' - as 
with git all your steps are mostly easily reversible as all branches are still 
there till prune point, while with this thin merging - one bad merge may 
present quite significant data lose. Also think about the difference in 
behavior between thin snaps and old thick snaps, where the merging worked 
differently and way way way more slower...

IMHO the correct name of such operation is replace/swap with thins.



  reply	other threads:[~2019-01-18  9:34 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
2019-01-18  0:53                   ` Davis, Matthew
2019-01-18  9:34                     ` Zdenek Kabelac [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).