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. | |
22 | You must create the snapshot-origin device before you can create snapshots. | |
23 | Reads will be mapped directly to the backing device. For each write, the | |
24 | original data will be saved in the <COW device> of each snapshot to keep | |
25 | its visible content unchanged, at least until the <COW device> fills up. | |
26 | ||
27 | ||
28 | *) snapshot <origin> <COW device> <persistent?> <chunksize> | |
29 | ||
30 | A snapshot is created of the <origin> block device. Changed chunks of | |
31 | <chunksize> sectors will be stored on the <COW device>. Writes will | |
32 | only go to the <COW device>. Reads will come from the <COW device> or | |
33 | from <origin> for unchanged data. <COW device> will often be | |
34 | smaller than the origin and if it fills up the snapshot will become | |
35 | useless and be disabled, returning errors. So it is important to monitor | |
36 | the amount of free space and expand the <COW device> before it fills up. | |
37 | ||
38 | <persistent?> is P (Persistent) or N (Not persistent - will not survive | |
39 | after reboot). | |
40 | ||
41 | ||
42 | How this is used by LVM2 | |
43 | ======================== | |
44 | When you create the first LVM2 snapshot of a volume, four dm devices are used: | |
45 | ||
46 | 1) a device containing the original mapping table of the source volume; | |
47 | 2) a device used as the <COW device>; | |
48 | 3) a "snapshot" device, combining #1 and #2, which is the visible snapshot | |
49 | volume; | |
50 | 4) the "original" volume (which uses the device number used by the original | |
51 | source volume), whose table is replaced by a "snapshot-origin" mapping | |
52 | from device #1. | |
53 | ||
54 | A fixed naming scheme is used, so with the following commands: | |
55 | ||
56 | lvcreate -L 1G -n base volumeGroup | |
57 | lvcreate -L 100M --snapshot -n snap volumeGroup/base | |
58 | ||
59 | we'll have this situation (with volumes in above order): | |
60 | ||
61 | # dmsetup table|grep volumeGroup | |
62 | ||
63 | volumeGroup-base-real: 0 2097152 linear 8:19 384 | |
64 | volumeGroup-snap-cow: 0 204800 linear 8:19 2097536 | |
65 | volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16 | |
66 | volumeGroup-base: 0 2097152 snapshot-origin 254:11 | |
67 | ||
68 | # ls -lL /dev/mapper/volumeGroup-* | |
69 | brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real | |
70 | brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow | |
71 | brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap | |
72 | brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base | |
73 |