Commit | Line | Data |
---|---|---|
e484585e PBG |
1 | Device-mapper snapshot support |
2 | ============================== | |
3 | ||
4 | Device-mapper allows you, without massive data copying: | |
5 | ||
6 | *) To create snapshots of any block device i.e. mountable, saved states of | |
7 | the block device which are also writable without interfering with the | |
8 | original content; | |
9 | *) To create device "forks", i.e. multiple different versions of the | |
10 | same data stream. | |
11 | ||
12 | ||
13 | In both cases, dm copies only the chunks of data that get changed and | |
14 | uses a separate copy-on-write (COW) block device for storage. | |
15 | ||
16 | ||
17 | There are two dm targets available: snapshot and snapshot-origin. | |
18 | ||
19 | *) snapshot-origin <origin> | |
20 | ||
21 | which will normally have one or more snapshots based on it. | |
e484585e PBG |
22 | Reads will be mapped directly to the backing device. For each write, the |
23 | original data will be saved in the <COW device> of each snapshot to keep | |
24 | its visible content unchanged, at least until the <COW device> fills up. | |
25 | ||
26 | ||
27 | *) snapshot <origin> <COW device> <persistent?> <chunksize> | |
28 | ||
411f1140 | 29 | A snapshot of the <origin> block device is created. Changed chunks of |
e484585e PBG |
30 | <chunksize> sectors will be stored on the <COW device>. Writes will |
31 | only go to the <COW device>. Reads will come from the <COW device> or | |
32 | from <origin> for unchanged data. <COW device> will often be | |
33 | smaller than the origin and if it fills up the snapshot will become | |
34 | useless and be disabled, returning errors. So it is important to monitor | |
35 | the amount of free space and expand the <COW device> before it fills up. | |
36 | ||
37 | <persistent?> is P (Persistent) or N (Not persistent - will not survive | |
38 | after reboot). | |
411f1140 PBG |
39 | The difference is that for transient snapshots less metadata must be |
40 | saved on disk - they can be kept in memory by the kernel. | |
e484585e PBG |
41 | |
42 | ||
43 | How this is used by LVM2 | |
44 | ======================== | |
45 | When you create the first LVM2 snapshot of a volume, four dm devices are used: | |
46 | ||
47 | 1) a device containing the original mapping table of the source volume; | |
48 | 2) a device used as the <COW device>; | |
49 | 3) a "snapshot" device, combining #1 and #2, which is the visible snapshot | |
50 | volume; | |
51 | 4) the "original" volume (which uses the device number used by the original | |
52 | source volume), whose table is replaced by a "snapshot-origin" mapping | |
53 | from device #1. | |
54 | ||
55 | A fixed naming scheme is used, so with the following commands: | |
56 | ||
57 | lvcreate -L 1G -n base volumeGroup | |
58 | lvcreate -L 100M --snapshot -n snap volumeGroup/base | |
59 | ||
60 | we'll have this situation (with volumes in above order): | |
61 | ||
62 | # dmsetup table|grep volumeGroup | |
63 | ||
64 | volumeGroup-base-real: 0 2097152 linear 8:19 384 | |
65 | volumeGroup-snap-cow: 0 204800 linear 8:19 2097536 | |
66 | volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16 | |
67 | volumeGroup-base: 0 2097152 snapshot-origin 254:11 | |
68 | ||
69 | # ls -lL /dev/mapper/volumeGroup-* | |
70 | brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real | |
71 | brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow | |
72 | brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap | |
73 | brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base | |
74 |