[linux-lvm] Snapshots of snapshots are not supported yet

[markw at mohawksoft.com]

> Dne 10.7.2013 16:45, markw at mohawksoft.com napsal(a):
>>> Dne 10.7.2013 05:45, markw at mohawksoft.com napsal(a):
>>> 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 :)

Ahh, ok.

>
>>
>>>
>>> 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

Well, yes, grabbing a new block and using it in the original volume would
be more efficient than copying old data to (n) snapshots. However, in the
system I wrote I only did the copy to one snapshot. All previous snaps
referred to the next newer snap in the chain.

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

Where's a good place to look to start?

>
> Zdenek
>
>