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 | c53a381e | 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 |