| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 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. | 
| Mikulas Patocka | d698aa4 | 2009-12-10 23:52:30 +0000 | [diff] [blame] | 11 | *) To merge a snapshot of a block device back into the snapshot's origin | 
 | 12 | device. | 
 | 13 |  | 
 | 14 | In the first two cases, dm copies only the chunks of data that get | 
 | 15 | changed and uses a separate copy-on-write (COW) block device for | 
 | 16 | storage. | 
 | 17 |  | 
 | 18 | For snapshot merge the contents of the COW storage are merged back into | 
 | 19 | the origin device. | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 20 |  | 
 | 21 |  | 
| Mikulas Patocka | d698aa4 | 2009-12-10 23:52:30 +0000 | [diff] [blame] | 22 | There are three dm targets available: | 
 | 23 | snapshot, snapshot-origin, and snapshot-merge. | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 24 |  | 
 | 25 | *) snapshot-origin <origin> | 
 | 26 |  | 
 | 27 | which will normally have one or more snapshots based on it. | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 28 | Reads will be mapped directly to the backing device. For each write, the | 
 | 29 | original data will be saved in the <COW device> of each snapshot to keep | 
 | 30 | its visible content unchanged, at least until the <COW device> fills up. | 
 | 31 |  | 
 | 32 |  | 
 | 33 | *) snapshot <origin> <COW device> <persistent?> <chunksize> | 
 | 34 |  | 
| Paolo 'Blaisorblade' Giarrusso | 411f114 | 2005-11-07 01:01:01 -0800 | [diff] [blame] | 35 | A snapshot of the <origin> block device is created. Changed chunks of | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 36 | <chunksize> sectors will be stored on the <COW device>.  Writes will | 
 | 37 | only go to the <COW device>.  Reads will come from the <COW device> or | 
 | 38 | from <origin> for unchanged data.  <COW device> will often be | 
 | 39 | smaller than the origin and if it fills up the snapshot will become | 
 | 40 | useless and be disabled, returning errors.  So it is important to monitor | 
 | 41 | the amount of free space and expand the <COW device> before it fills up. | 
 | 42 |  | 
 | 43 | <persistent?> is P (Persistent) or N (Not persistent - will not survive | 
 | 44 | after reboot). | 
| Paolo 'Blaisorblade' Giarrusso | 411f114 | 2005-11-07 01:01:01 -0800 | [diff] [blame] | 45 | The difference is that for transient snapshots less metadata must be | 
 | 46 | saved on disk - they can be kept in memory by the kernel. | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 47 |  | 
 | 48 |  | 
| Mikulas Patocka | d698aa4 | 2009-12-10 23:52:30 +0000 | [diff] [blame] | 49 | * snapshot-merge <origin> <COW device> <persistent> <chunksize> | 
 | 50 |  | 
 | 51 | takes the same table arguments as the snapshot target except it only | 
 | 52 | works with persistent snapshots.  This target assumes the role of the | 
 | 53 | "snapshot-origin" target and must not be loaded if the "snapshot-origin" | 
 | 54 | is still present for <origin>. | 
 | 55 |  | 
 | 56 | Creates a merging snapshot that takes control of the changed chunks | 
 | 57 | stored in the <COW device> of an existing snapshot, through a handover | 
 | 58 | procedure, and merges these chunks back into the <origin>.  Once merging | 
 | 59 | has started (in the background) the <origin> may be opened and the merge | 
 | 60 | will continue while I/O is flowing to it.  Changes to the <origin> are | 
 | 61 | deferred until the merging snapshot's corresponding chunk(s) have been | 
 | 62 | merged.  Once merging has started the snapshot device, associated with | 
 | 63 | the "snapshot" target, will return -EIO when accessed. | 
 | 64 |  | 
 | 65 |  | 
 | 66 | How snapshot is used by LVM2 | 
 | 67 | ============================ | 
| Paolo 'Blaisorblade' Giarrusso | e484585 | 2005-09-22 21:44:29 -0700 | [diff] [blame] | 68 | When you create the first LVM2 snapshot of a volume, four dm devices are used: | 
 | 69 |  | 
 | 70 | 1) a device containing the original mapping table of the source volume; | 
 | 71 | 2) a device used as the <COW device>; | 
 | 72 | 3) a "snapshot" device, combining #1 and #2, which is the visible snapshot | 
 | 73 |    volume; | 
 | 74 | 4) the "original" volume (which uses the device number used by the original | 
 | 75 |    source volume), whose table is replaced by a "snapshot-origin" mapping | 
 | 76 |    from device #1. | 
 | 77 |  | 
 | 78 | A fixed naming scheme is used, so with the following commands: | 
 | 79 |  | 
 | 80 | lvcreate -L 1G -n base volumeGroup | 
 | 81 | lvcreate -L 100M --snapshot -n snap volumeGroup/base | 
 | 82 |  | 
 | 83 | we'll have this situation (with volumes in above order): | 
 | 84 |  | 
 | 85 | # dmsetup table|grep volumeGroup | 
 | 86 |  | 
 | 87 | volumeGroup-base-real: 0 2097152 linear 8:19 384 | 
 | 88 | volumeGroup-snap-cow: 0 204800 linear 8:19 2097536 | 
 | 89 | volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16 | 
 | 90 | volumeGroup-base: 0 2097152 snapshot-origin 254:11 | 
 | 91 |  | 
 | 92 | # ls -lL /dev/mapper/volumeGroup-* | 
 | 93 | brw-------  1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real | 
 | 94 | brw-------  1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow | 
 | 95 | brw-------  1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap | 
 | 96 | brw-------  1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base | 
 | 97 |  | 
| Mikulas Patocka | d698aa4 | 2009-12-10 23:52:30 +0000 | [diff] [blame] | 98 |  | 
 | 99 | How snapshot-merge is used by LVM2 | 
 | 100 | ================================== | 
 | 101 | A merging snapshot assumes the role of the "snapshot-origin" while | 
 | 102 | merging.  As such the "snapshot-origin" is replaced with | 
 | 103 | "snapshot-merge".  The "-real" device is not changed and the "-cow" | 
 | 104 | device is renamed to <origin name>-cow to aid LVM2's cleanup of the | 
 | 105 | merging snapshot after it completes.  The "snapshot" that hands over its | 
 | 106 | COW device to the "snapshot-merge" is deactivated (unless using lvchange | 
 | 107 | --refresh); but if it is left active it will simply return I/O errors. | 
 | 108 |  | 
 | 109 | A snapshot will merge into its origin with the following command: | 
 | 110 |  | 
 | 111 | lvconvert --merge volumeGroup/snap | 
 | 112 |  | 
 | 113 | we'll now have this situation: | 
 | 114 |  | 
 | 115 | # dmsetup table|grep volumeGroup | 
 | 116 |  | 
 | 117 | volumeGroup-base-real: 0 2097152 linear 8:19 384 | 
 | 118 | volumeGroup-base-cow: 0 204800 linear 8:19 2097536 | 
 | 119 | volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16 | 
 | 120 |  | 
 | 121 | # ls -lL /dev/mapper/volumeGroup-* | 
 | 122 | brw-------  1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real | 
 | 123 | brw-------  1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow | 
 | 124 | brw-------  1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base | 
| Mike Snitzer | c53a381 | 2010-03-06 02:29:56 +0000 | [diff] [blame] | 125 |  | 
 | 126 |  | 
 | 127 | How to determine when a merging is complete | 
 | 128 | =========================================== | 
 | 129 | The snapshot-merge and snapshot status lines end with: | 
 | 130 |   <sectors_allocated>/<total_sectors> <metadata_sectors> | 
 | 131 |  | 
 | 132 | Both <sectors_allocated> and <total_sectors> include both data and metadata. | 
 | 133 | During merging, the number of sectors allocated gets smaller and | 
 | 134 | smaller.  Merging has finished when the number of sectors holding data | 
 | 135 | is zero, in other words <sectors_allocated> == <metadata_sectors>. | 
 | 136 |  | 
 | 137 | Here is a practical example (using a hybrid of lvm and dmsetup commands): | 
 | 138 |  | 
 | 139 | # lvs | 
 | 140 |   LV      VG          Attr   LSize Origin  Snap%  Move Log Copy%  Convert | 
 | 141 |   base    volumeGroup owi-a- 4.00g | 
 | 142 |   snap    volumeGroup swi-a- 1.00g base  18.97 | 
 | 143 |  | 
 | 144 | # dmsetup status volumeGroup-snap | 
 | 145 | 0 8388608 snapshot 397896/2097152 1560 | 
 | 146 |                                   ^^^^ metadata sectors | 
 | 147 |  | 
 | 148 | # lvconvert --merge -b volumeGroup/snap | 
 | 149 |   Merging of volume snap started. | 
 | 150 |  | 
 | 151 | # lvs volumeGroup/snap | 
 | 152 |   LV      VG          Attr   LSize Origin  Snap%  Move Log Copy%  Convert | 
 | 153 |   base    volumeGroup Owi-a- 4.00g          17.23 | 
 | 154 |  | 
 | 155 | # dmsetup status volumeGroup-base | 
 | 156 | 0 8388608 snapshot-merge 281688/2097152 1104 | 
 | 157 |  | 
 | 158 | # dmsetup status volumeGroup-base | 
 | 159 | 0 8388608 snapshot-merge 180480/2097152 712 | 
 | 160 |  | 
 | 161 | # dmsetup status volumeGroup-base | 
 | 162 | 0 8388608 snapshot-merge 16/2097152 16 | 
 | 163 |  | 
 | 164 | Merging has finished. | 
 | 165 |  | 
 | 166 | # lvs | 
 | 167 |   LV      VG          Attr   LSize Origin  Snap%  Move Log Copy%  Convert | 
 | 168 |   base    volumeGroup owi-a- 4.00g |