From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: markw@mohawksoft.com
Subject: Re: [linux-lvm] Snapshots of snapshots are not supported yet
Date: Wed, 10 Jul 2013 20:43:15 +0200 [thread overview]
Message-ID: <51DDAB43.7070001@redhat.com> (raw)
In-Reply-To: <741f708c46ffac16eeab39629823d5c2.squirrel@mail.mohawksoft.com>
Dne 10.7.2013 16:45, markw@mohawksoft.com napsal(a):
>> Dne 10.7.2013 05:45, markw@mohawksoft.com napsal(a):
>>> One more annoying question, if you have the patience.
>>>
>>> Suppose I create a thin provisioned volume, say disk0.
>>>
>>> I take a snapshot of disk0 and name it disk0_snap0
>>> After a number of changes I then take another snapshot, and call it
>>> disk0_snap1
>>>
>>> Is the thin provisioning stuff smart enough to realize that disk0_snap0
>>> should be rewired to reference disk0_snap1 as its origin? It would look
>>> like this:
>>>
>>> disk0 -> disk0_snap1 -> disk0_snap0
>>>
>>> What I would like to see is something like this:
>>>
>>> disk0 -> disk0_snap2 -> disk0_snap1 -> disk0_snap0
>>>
>>> Create disk0_snap3
>>>
>>> disk0 -> disk0_snap3 -> disk0_snap2 -> disk0_snap1 -> disk0_snap0
>>>
>>> Where all writes to disk0 result in CoW to disk0_snap3 and the remaining
>>> snaps remain unchanged.
>>>
>>> Here is the kicker, I want to perform a differential backup on
>>> disk0_snap3
>>> and disk0_snap2. Suppose I already recreated disk0_snap2 on some
>>> server.
>>> I now want to update it to disk0_snap3. I need to get a block list from
>>> disk0_snap2 and disk0_snap3, then generate a list of blocks needed to
>>> permute snap2 to snap3.
>>>
>>> Any info?
>>>
>>
>> Yes - differential snapshot will be supported through thin provisioning
>> target - where you will be able to make a simple diff just by reading
>> metadata - it will be essential piece of replication.
>
> Is any of this in place now?
Surely not - if it would be in place - I'd suggest which command you should use :)
>
>>
>> AFAIK Joe has this in plan for some time - and there was even some
>> announcement from some third-party developer to support this.
>
> Do you have a link?
https://www.redhat.com/archives/dm-devel/2013-July/msg00005.html
>>
>> There is not going to be any upstream support for doing this with
>> old-snaps in foreseeable future.
>>
>> Also keep in mind your idea of using old-snap of snap of snap would be
>> very
>> slow and fragile to use.
>
> Well, the reason I am pursuing this.....
>
> At a previous employment a few years back, I created a system using LVM2,
> old style snapshots, and FUSE to create this functionality.
>
> Using my previous example as a reference
>
> disk0 would always have one live snapshot to maintain diffs, call it
> disk0_snap_root.
Using chain of old-snaps is just way too heavy for anything - you really need
to use system which is not copying blocks
> I need to implement similar behavior at a new employer and really really
> want not to use FUSE and rewrite all that crap again and am trying to see
> how to get it done using the device mapper layer. Also this is going to be
> for a product that is expected to ship to customers in the relatively near
> term.
>
> Any information or insight you can share would be much appreciated. I am
> beginning to suspect that LVM will not be usable for the project.
As I said - btrfs has some kind of functionality you are looking for,
Or you may start to help with lvm project...
(Or thin-provisioning tools in this case)
Zdenek
next prev parent reply other threads:[~2013-07-10 18:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 16:05 [linux-lvm] Snapshots of snapshots are not supported yet markw
2013-07-08 17:41 ` Zdenek Kabelac
2013-07-08 17:57 ` markw
2013-07-08 19:03 ` Zdenek Kabelac
2013-07-10 3:45 ` markw
2013-07-10 8:25 ` Zdenek Kabelac
2013-07-10 14:45 ` markw
2013-07-10 18:43 ` Zdenek Kabelac [this message]
2013-07-10 19:16 ` markw
2013-07-10 20:12 ` markw
2013-07-10 20:15 ` 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=51DDAB43.7070001@redhat.com \
--to=zkabelac@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=markw@mohawksoft.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).