|
@@ -8,13 +8,19 @@ the block device which are also writable without interfering with the
|
|
|
original content;
|
|
|
*) To create device "forks", i.e. multiple different versions of the
|
|
|
same data stream.
|
|
|
+*) To merge a snapshot of a block device back into the snapshot's origin
|
|
|
+device.
|
|
|
|
|
|
+In the first two cases, dm copies only the chunks of data that get
|
|
|
+changed and uses a separate copy-on-write (COW) block device for
|
|
|
+storage.
|
|
|
|
|
|
-In both cases, dm copies only the chunks of data that get changed and
|
|
|
-uses a separate copy-on-write (COW) block device for storage.
|
|
|
+For snapshot merge the contents of the COW storage are merged back into
|
|
|
+the origin device.
|
|
|
|
|
|
|
|
|
-There are two dm targets available: snapshot and snapshot-origin.
|
|
|
+There are three dm targets available:
|
|
|
+snapshot, snapshot-origin, and snapshot-merge.
|
|
|
|
|
|
*) snapshot-origin <origin>
|
|
|
|
|
@@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be
|
|
|
saved on disk - they can be kept in memory by the kernel.
|
|
|
|
|
|
|
|
|
-How this is used by LVM2
|
|
|
-========================
|
|
|
+* snapshot-merge <origin> <COW device> <persistent> <chunksize>
|
|
|
+
|
|
|
+takes the same table arguments as the snapshot target except it only
|
|
|
+works with persistent snapshots. This target assumes the role of the
|
|
|
+"snapshot-origin" target and must not be loaded if the "snapshot-origin"
|
|
|
+is still present for <origin>.
|
|
|
+
|
|
|
+Creates a merging snapshot that takes control of the changed chunks
|
|
|
+stored in the <COW device> of an existing snapshot, through a handover
|
|
|
+procedure, and merges these chunks back into the <origin>. Once merging
|
|
|
+has started (in the background) the <origin> may be opened and the merge
|
|
|
+will continue while I/O is flowing to it. Changes to the <origin> are
|
|
|
+deferred until the merging snapshot's corresponding chunk(s) have been
|
|
|
+merged. Once merging has started the snapshot device, associated with
|
|
|
+the "snapshot" target, will return -EIO when accessed.
|
|
|
+
|
|
|
+
|
|
|
+How snapshot is used by LVM2
|
|
|
+============================
|
|
|
When you create the first LVM2 snapshot of a volume, four dm devices are used:
|
|
|
|
|
|
1) a device containing the original mapping table of the source volume;
|
|
@@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow
|
|
|
brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap
|
|
|
brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base
|
|
|
|
|
|
+
|
|
|
+How snapshot-merge is used by LVM2
|
|
|
+==================================
|
|
|
+A merging snapshot assumes the role of the "snapshot-origin" while
|
|
|
+merging. As such the "snapshot-origin" is replaced with
|
|
|
+"snapshot-merge". The "-real" device is not changed and the "-cow"
|
|
|
+device is renamed to <origin name>-cow to aid LVM2's cleanup of the
|
|
|
+merging snapshot after it completes. The "snapshot" that hands over its
|
|
|
+COW device to the "snapshot-merge" is deactivated (unless using lvchange
|
|
|
+--refresh); but if it is left active it will simply return I/O errors.
|
|
|
+
|
|
|
+A snapshot will merge into its origin with the following command:
|
|
|
+
|
|
|
+lvconvert --merge volumeGroup/snap
|
|
|
+
|
|
|
+we'll now have this situation:
|
|
|
+
|
|
|
+# dmsetup table|grep volumeGroup
|
|
|
+
|
|
|
+volumeGroup-base-real: 0 2097152 linear 8:19 384
|
|
|
+volumeGroup-base-cow: 0 204800 linear 8:19 2097536
|
|
|
+volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16
|
|
|
+
|
|
|
+# ls -lL /dev/mapper/volumeGroup-*
|
|
|
+brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real
|
|
|
+brw------- 1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow
|
|
|
+brw------- 1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base
|