75 lines
2.9 KiB
Plaintext
75 lines
2.9 KiB
Plaintext
|
Device-mapper snapshot support
|
||
|
|
==============================
|
||
|
|
|
||
|
|
Device-mapper allows you, without massive data copying:
|
||
|
|
|
||
|
|
*) To create snapshots of any block device i.e. mountable, saved states of
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
There are two dm targets available: snapshot and snapshot-origin.
|
||
|
|
|
||
|
|
*) snapshot-origin <origin>
|
||
|
|
|
||
|
|
which will normally have one or more snapshots based on it.
|
||
|
|
Reads will be mapped directly to the backing device. For each write, the
|
||
|
|
original data will be saved in the <COW device> of each snapshot to keep
|
||
|
|
its visible content unchanged, at least until the <COW device> fills up.
|
||
|
|
|
||
|
|
|
||
|
|
*) snapshot <origin> <COW device> <persistent?> <chunksize>
|
||
|
|
|
||
|
|
A snapshot of the <origin> block device is created. Changed chunks of
|
||
|
|
<chunksize> sectors will be stored on the <COW device>. Writes will
|
||
|
|
only go to the <COW device>. Reads will come from the <COW device> or
|
||
|
|
from <origin> for unchanged data. <COW device> will often be
|
||
|
|
smaller than the origin and if it fills up the snapshot will become
|
||
|
|
useless and be disabled, returning errors. So it is important to monitor
|
||
|
|
the amount of free space and expand the <COW device> before it fills up.
|
||
|
|
|
||
|
|
<persistent?> is P (Persistent) or N (Not persistent - will not survive
|
||
|
|
after reboot).
|
||
|
|
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
|
||
|
|
========================
|
||
|
|
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;
|
||
|
|
2) a device used as the <COW device>;
|
||
|
|
3) a "snapshot" device, combining #1 and #2, which is the visible snapshot
|
||
|
|
volume;
|
||
|
|
4) the "original" volume (which uses the device number used by the original
|
||
|
|
source volume), whose table is replaced by a "snapshot-origin" mapping
|
||
|
|
from device #1.
|
||
|
|
|
||
|
|
A fixed naming scheme is used, so with the following commands:
|
||
|
|
|
||
|
|
lvcreate -L 1G -n base volumeGroup
|
||
|
|
lvcreate -L 100M --snapshot -n snap volumeGroup/base
|
||
|
|
|
||
|
|
we'll have this situation (with volumes in above order):
|
||
|
|
|
||
|
|
# dmsetup table|grep volumeGroup
|
||
|
|
|
||
|
|
volumeGroup-base-real: 0 2097152 linear 8:19 384
|
||
|
|
volumeGroup-snap-cow: 0 204800 linear 8:19 2097536
|
||
|
|
volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16
|
||
|
|
volumeGroup-base: 0 2097152 snapshot-origin 254:11
|
||
|
|
|
||
|
|
# 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: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
|
||
|
|
|