On Fri, Apr 17, 2009 at 3:04 PM, Jonathan Brassow <jbrassow@xxxxxxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
