Lines Matching full:dm

4 dm-clone
10 dm-clone is a device mapper target which produces a one-to-one copy of an
15 The main use case of dm-clone is to clone a potentially remote, high-latency,
26 When the cloning completes, the dm-clone table can be removed altogether and be
29 The dm-clone target reuses the metadata library used by the thin-provisioning
68 dm-clone divides the source and destination devices in fixed sized regions.
72 The region size is configurable when you first create the dm-clone device. The
92 dm-clone interprets a discard request to a range that hasn't been hydrated yet
97 If the destination device supports discards, then by default dm-clone will pass
103 dm-clone copies continuously from the source to the destination device, until
108 any one time. Moreover, dm-clone takes into account user I/O traffic going to
114 dm-clone employs dm-kcopyd for copying portions of the source device to the
118 dm-clone trying to batch together contiguous regions, so we copy the data in
121 When the hydration of the destination device finishes, a dm event will be sent
129 dm-clone device behaves like a physical disk that has a volatile write cache. If
154                   passed to dm-clone
155  core args        Key/value pairs passed to dm-clone, e.g. `hydration_threshold
162  no_hydration         Create a dm-clone instance with background hydration
207                          mode changes, a dm event will be sent to user space.
231 1. Create the dm-clone device.
238 2. Mount the device and trim the file system. dm-clone interprets the discards
252 4. When the hydration finishes, we can replace the dm-clone table with a linear
280    hydration after a number of failures and emit a dm event for user space to
286 We explored the following alternatives before implementing dm-clone:
288 1. Use dm-cache with cache size equal to the source device and implement a new
294    * dm-cache writes to the source device, which violates our requirement that
299 2. Use dm-snapshot with a COW device equal to the source device:
301    * dm-snapshot stores its metadata in the COW device, so the resulting device
306    * dm-snapshot needs to commit its metadata whenever a pending exception
309      or FUA bio is written, or periodically, like dm-thin and dm-cache do. This
312 3. Use dm-mirror: The mirror target has a background copying/mirroring
316 4. Use dm-thin's external snapshot functionality. This approach is the most
319    un-provisioned/not-yet-cloned areas the same way as dm-clone does.
333    LV as dm-clone's destination device.