diff options
| -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 | |||
