Recientemente the news was released that the creator of the Linux kernel, "Linus Torvalds" accepted into the core branch (on the basis of which version 5.4 is formed) the implementation of the dm-clone module with the implementation of a new controller based on Device-Mapper.
This new proposal for Linux kernel will allow you to clone an existing block device. The module allows to create a local copy based on a read-only block device that can be written to during the cloning process.
As a typical application of the proposed module for the Linux Kernel "Dm-clone" refers to network cloning of remote file devices in read-only mode and I / O processing with long delays, to a fast local device that supports recording and processing requests with minimal delays.
With it provides the ability to mount the cloned device and start using it immediately after its creation, without waiting for the data transfer process to finish.
While on the other hand the copying of information will continue in the background, in parallel with the input / output generated when accessing a new device.
The main use case for dm-clone is to clone a potentially remote latency, read-only file-type locking device onto a writable primary-type device.
E.g. dm-clone can be used to restore attached storage backups to the network available via protocols such as NBD, Fiber Channel, iSCSI and AoE on local storage based on SSD or NVMe.
The dm-clone code is optimized for small random writes whose size matches the block size (4K by default).
During the cloning process, read requests will lead to a direct request for data from the cloned device and write requests affecting areas that have not yet been synced will be delayed until the unscheduled loading of the requested blocks is completed (the loading operations for the recording-related blocks start instantly).
Blocks removed by the "discard" operation are excluded from the copy process (after mounting, the user can execute "fstrim / mnt / cloned-fs" to avoid copying blocks that are not used in the FS).
Information about changes and data in loaded blocks they are stored in a separate local metadata table.
After cloning is complete, the user receives a full working copy of the source device, reflecting all changes made since the start of cloning.
A table with clone metadata can be dropped after synchronization by replacing it with a table of lines that directly reflects the data to a new device.
The key difference from Unionfs and OverlayFS based solutions is that dm-clone works at the block device level, regardless of the file system used on this device, and forms a complete copy of the source device and does not impose an additional layer. where changes are tracked.
Unlike dm-mirror, the dm-clone module was originally designed to work only with the original section in read-only mode, without translating write operations to it.
In dm-snapshot, a full copy is not created and background copy is not supported. In dm-cache, a full copy is not created, write operations are forwarded, and work is reduced to caching hits. The closest functionality is dm-thin.
dm-clone uses dm-kcopyd to copy parts of the source device to the target device. By default, copy requests of a size equal to the size of the region are issued.
A `hydration_batch_size <#regions>` message can be used to adjust the size of these copy requests. Increasing the hydration batch size results in dm-clone trying to group contiguous regions together, so we batch copy data from these many regions.
Source: https://git.kernel.org