diff options
Diffstat (limited to 'Documentation/device-mapper/snapshot.txt')
-rw-r--r-- | Documentation/device-mapper/snapshot.txt | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/Documentation/device-mapper/snapshot.txt b/Documentation/device-mapper/snapshot.txt new file mode 100644 index 000000000000..dca274ff4005 --- /dev/null +++ b/Documentation/device-mapper/snapshot.txt | |||
@@ -0,0 +1,73 @@ | |||
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 | |||