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

[Kyle Moffett]

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