projects / linux-2.6-block.git / blame
| 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 |