[dm-devel] [PATCH] DM Snapshot: snapshot-merge target

Jonathan Brassow jbrassow at redhat.com
Tue Apr 21 20:07:09 UTC 2009


I'm not so sure about that approach...

I've also posted a "shared" exception store (which has a long history  
of contributors), which allows for better space and performance  
efficiency.

I think you could achieve the same thing without the added complexity.

  brassow

On Apr 19, 2009, at 7:49 PM, Kyle Moffett wrote:

> On Fri, Apr 17, 2009 at 3:04 PM, Jonathan Brassow  
> <jbrassow at redhat.com> wrote:
>> This patch introduces the "snapshot-merge" target.  This target can  
>> be
>> used to merge a snapshot into an origin - amoung other uses.  The
>> constructor table is almost identical to the snapshot target.
>>
>> snapshot table      : <start> <len> snapshot       <real-origin>  
>> <exstore args>
>> snapshot-merge table: <start> <len> snapshot-merge <virt-origin>  
>> <exstore args>
>>
>> When you create a device-mapper "snapshot-origin" device, the  
>> device you
>> interface with is the 'virt-origin', while the device it covers is  
>> the
>> 'real-origin'.
>>
>> The benefit of using the 'virt-origin' in the snapshot-merge table  
>> is that
>> doing so will preserve all the other snapshots that were made  
>> against the
>> origin.  If you specify the 'real-origin', the other snapshots (the  
>> ones
>> you are not merging) would be corrupted.  [There are reasons for  
>> using the
>> underlying 'real' devices, though.  More on this later.]
>
> Hmm, this is very interesting...  I'd be inclined to use this as a way
> of storing temporary sequential backups.  Specifically, I would have a
> base device and a series of chained snapshots, set up in a tree so
> that the base device is perhaps several years old, with a snapshot
> dated one year later, with another snapshot dated one year later whose
> origin is the previous snapshot, etc.  That would go up to the
> beginning of the current year, where we would then have monthly
> snapshots up to a month or two ago, followed by weekly snapshots until
> a week or two ago, ..... until we get down to 15-minute-interval
> snapshots over the last hour or two.
>
> The benefit over same-origin snapshots would be that deltas are only
> stored once, and once a snapshot is no longer the "current snapshot"
> it can be marked read-only and be shrunk to fit.  As snapshots push
> across a change-in-frequency boundary (IE: daily snapshots become more
> than 2 weeks old, for example), they would be merged together.  Using
> the daily snapshot example, the first-day-of-the-week snapshot would
> be expanded to the total size of that week's snapshots and marked R/W
> again, then all the others would be sequentially merged into it.
>
> There would of course be some performance issues accessing
> long-unmodified data on the origin volume.  Specifically, accessing
> long-unmodified data on the origin volume would require looking
> through some 30 different exception tables to figure out precisely
> which snapshot it's on, but that might be worth the benefit for the
> very space-efficient history.
>
> Cheers,
> Kyle Moffett
>
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel




More information about the dm-devel mailing list