334 lines · plain
1.. SPDX-License-Identifier: GPL-2.0-only2 3========4dm-clone5========6 7Introduction8============9 10dm-clone is a device mapper target which produces a one-to-one copy of an11existing, read-only source device into a writable destination device: It12presents a virtual block device which makes all data appear immediately, and13redirects reads and writes accordingly.14 15The main use case of dm-clone is to clone a potentially remote, high-latency,16read-only, archival-type block device into a writable, fast, primary-type device17for fast, low-latency I/O. The cloned device is visible/mountable immediately18and the copy of the source device to the destination device happens in the19background, in parallel with user I/O.20 21For example, one could restore an application backup from a read-only copy,22accessible through a network storage protocol (NBD, Fibre Channel, iSCSI, AoE,23etc.), into a local SSD or NVMe device, and start using the device immediately,24without waiting for the restore to complete.25 26When the cloning completes, the dm-clone table can be removed altogether and be27replaced, e.g., by a linear table, mapping directly to the destination device.28 29The dm-clone target reuses the metadata library used by the thin-provisioning30target.31 32Glossary33========34 35 Hydration36 The process of filling a region of the destination device with data from37 the same region of the source device, i.e., copying the region from the38 source to the destination device.39 40Once a region gets hydrated we redirect all I/O regarding it to the destination41device.42 43Design44======45 46Sub-devices47-----------48 49The target is constructed by passing three devices to it (along with other50parameters detailed later):51 521. A source device - the read-only device that gets cloned and source of the53 hydration.54 552. A destination device - the destination of the hydration, which will become a56 clone of the source device.57 583. A small metadata device - it records which regions are already valid in the59 destination device, i.e., which regions have already been hydrated, or have60 been written to directly, via user I/O.61 62The size of the destination device must be at least equal to the size of the63source device.64 65Regions66-------67 68dm-clone divides the source and destination devices in fixed sized regions.69Regions are the unit of hydration, i.e., the minimum amount of data copied from70the source to the destination device.71 72The region size is configurable when you first create the dm-clone device. The73recommended region size is the same as the file system block size, which usually74is 4KB. The region size must be between 8 sectors (4KB) and 2097152 sectors75(1GB) and a power of two.76 77Reads and writes from/to hydrated regions are serviced from the destination78device.79 80A read to a not yet hydrated region is serviced directly from the source device.81 82A write to a not yet hydrated region will be delayed until the corresponding83region has been hydrated and the hydration of the region starts immediately.84 85Note that a write request with size equal to region size will skip copying of86the corresponding region from the source device and overwrite the region of the87destination device directly.88 89Discards90--------91 92dm-clone interprets a discard request to a range that hasn't been hydrated yet93as a hint to skip hydration of the regions covered by the request, i.e., it94skips copying the region's data from the source to the destination device, and95only updates its metadata.96 97If the destination device supports discards, then by default dm-clone will pass98down discard requests to it.99 100Background Hydration101--------------------102 103dm-clone copies continuously from the source to the destination device, until104all of the device has been copied.105 106Copying data from the source to the destination device uses bandwidth. The user107can set a throttle to prevent more than a certain amount of copying occurring at108any one time. Moreover, dm-clone takes into account user I/O traffic going to109the devices and pauses the background hydration when there is I/O in-flight.110 111A message `hydration_threshold <#regions>` can be used to set the maximum number112of regions being copied, the default being 1 region.113 114dm-clone employs dm-kcopyd for copying portions of the source device to the115destination device. By default, we issue copy requests of size equal to the116region size. A message `hydration_batch_size <#regions>` can be used to tune the117size of these copy requests. Increasing the hydration batch size results in118dm-clone trying to batch together contiguous regions, so we copy the data in119batches of this many regions.120 121When the hydration of the destination device finishes, a dm event will be sent122to user space.123 124Updating on-disk metadata125-------------------------126 127On-disk metadata is committed every time a FLUSH or FUA bio is written. If no128such requests are made then commits will occur every second. This means the129dm-clone device behaves like a physical disk that has a volatile write cache. If130power is lost you may lose some recent writes. The metadata should always be131consistent in spite of any crash.132 133Target Interface134================135 136Constructor137-----------138 139 ::140 141 clone <metadata dev> <destination dev> <source dev> <region size>142 [<#feature args> [<feature arg>]* [<#core args> [<core arg>]*]]143 144 ================ ==============================================================145 metadata dev Fast device holding the persistent metadata146 destination dev The destination device, where the source will be cloned147 source dev Read only device containing the data that gets cloned148 region size The size of a region in sectors149 150 #feature args Number of feature arguments passed151 feature args no_hydration or no_discard_passdown152 153 #core args An even number of arguments corresponding to key/value pairs154 passed to dm-clone155 core args Key/value pairs passed to dm-clone, e.g. `hydration_threshold156 256`157 ================ ==============================================================158 159Optional feature arguments are:160 161 ==================== =========================================================162 no_hydration Create a dm-clone instance with background hydration163 disabled164 no_discard_passdown Disable passing down discards to the destination device165 ==================== =========================================================166 167Optional core arguments are:168 169 ================================ ==============================================170 hydration_threshold <#regions> Maximum number of regions being copied from171 the source to the destination device at any172 one time, during background hydration.173 hydration_batch_size <#regions> During background hydration, try to batch174 together contiguous regions, so we copy data175 from the source to the destination device in176 batches of this many regions.177 ================================ ==============================================178 179Status180------181 182 ::183 184 <metadata block size> <#used metadata blocks>/<#total metadata blocks>185 <region size> <#hydrated regions>/<#total regions> <#hydrating regions>186 <#feature args> <feature args>* <#core args> <core args>*187 <clone metadata mode>188 189 ======================= =======================================================190 metadata block size Fixed block size for each metadata block in sectors191 #used metadata blocks Number of metadata blocks used192 #total metadata blocks Total number of metadata blocks193 region size Configurable region size for the device in sectors194 #hydrated regions Number of regions that have finished hydrating195 #total regions Total number of regions to hydrate196 #hydrating regions Number of regions currently hydrating197 #feature args Number of feature arguments to follow198 feature args Feature arguments, e.g. `no_hydration`199 #core args Even number of core arguments to follow200 core args Key/value pairs for tuning the core, e.g.201 `hydration_threshold 256`202 clone metadata mode ro if read-only, rw if read-write203 204 In serious cases where even a read-only mode is deemed205 unsafe no further I/O will be permitted and the status206 will just contain the string 'Fail'. If the metadata207 mode changes, a dm event will be sent to user space.208 ======================= =======================================================209 210Messages211--------212 213 `disable_hydration`214 Disable the background hydration of the destination device.215 216 `enable_hydration`217 Enable the background hydration of the destination device.218 219 `hydration_threshold <#regions>`220 Set background hydration threshold.221 222 `hydration_batch_size <#regions>`223 Set background hydration batch size.224 225Examples226========227 228Clone a device containing a file system229---------------------------------------230 2311. Create the dm-clone device.232 233 ::234 235 dmsetup create clone --table "0 1048576000 clone $metadata_dev $dest_dev \236 $source_dev 8 1 no_hydration"237 2382. Mount the device and trim the file system. dm-clone interprets the discards239 sent by the file system and it will not hydrate the unused space.240 241 ::242 243 mount /dev/mapper/clone /mnt/cloned-fs244 fstrim /mnt/cloned-fs245 2463. Enable background hydration of the destination device.247 248 ::249 250 dmsetup message clone 0 enable_hydration251 2524. When the hydration finishes, we can replace the dm-clone table with a linear253 table.254 255 ::256 257 dmsetup suspend clone258 dmsetup load clone --table "0 1048576000 linear $dest_dev 0"259 dmsetup resume clone260 261 The metadata device is no longer needed and can be safely discarded or reused262 for other purposes.263 264Known issues265============266 2671. We redirect reads, to not-yet-hydrated regions, to the source device. If268 reading the source device has high latency and the user repeatedly reads from269 the same regions, this behaviour could degrade performance. We should use270 these reads as hints to hydrate the relevant regions sooner. Currently, we271 rely on the page cache to cache these regions, so we hopefully don't end up272 reading them multiple times from the source device.273 2742. Release in-core resources, i.e., the bitmaps tracking which regions are275 hydrated, after the hydration has finished.276 2773. During background hydration, if we fail to read the source or write to the278 destination device, we print an error message, but the hydration process279 continues indefinitely, until it succeeds. We should stop the background280 hydration after a number of failures and emit a dm event for user space to281 notice.282 283Why not...?284===========285 286We explored the following alternatives before implementing dm-clone:287 2881. Use dm-cache with cache size equal to the source device and implement a new289 cloning policy:290 291 * The resulting cache device is not a one-to-one mirror of the source device292 and thus we cannot remove the cache device once cloning completes.293 294 * dm-cache writes to the source device, which violates our requirement that295 the source device must be treated as read-only.296 297 * Caching is semantically different from cloning.298 2992. Use dm-snapshot with a COW device equal to the source device:300 301 * dm-snapshot stores its metadata in the COW device, so the resulting device302 is not a one-to-one mirror of the source device.303 304 * No background copying mechanism.305 306 * dm-snapshot needs to commit its metadata whenever a pending exception307 completes, to ensure snapshot consistency. In the case of cloning, we don't308 need to be so strict and can rely on committing metadata every time a FLUSH309 or FUA bio is written, or periodically, like dm-thin and dm-cache do. This310 improves the performance significantly.311 3123. Use dm-mirror: The mirror target has a background copying/mirroring313 mechanism, but it writes to all mirrors, thus violating our requirement that314 the source device must be treated as read-only.315 3164. Use dm-thin's external snapshot functionality. This approach is the most317 promising among all alternatives, as the thinly-provisioned volume is a318 one-to-one mirror of the source device and handles reads and writes to319 un-provisioned/not-yet-cloned areas the same way as dm-clone does.320 321 Still:322 323 * There is no background copying mechanism, though one could be implemented.324 325 * Most importantly, we want to support arbitrary block devices as the326 destination of the cloning process and not restrict ourselves to327 thinly-provisioned volumes. Thin-provisioning has an inherent metadata328 overhead, for maintaining the thin volume mappings, which significantly329 degrades performance.330 331 Moreover, cloning a device shouldn't force the use of thin-provisioning. On332 the other hand, if we wish to use thin provisioning, we can just use a thin333 LV as dm-clone's destination device.334