요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Target interface와 예제
dm-clone.rst:133-263Constructor, status, runtime message와 file-system clone 후 linear table로 전환하는 절차를 설명합니다.
한계와 대안 비교
dm-clone.rst:264-333Known issue와 dm-cache, dm-snapshot, dm-mirror, dm-thin을 대신 사용하지 않은 이유를 비교합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0-only
========
dm-clone
========
Introduction
============
dm-clone is a device mapper target which produces a one-to-one copy of an
existing, read-only source device into a writable destination device: It
presents a virtual block device which makes all data appear immediately, and
redirects reads and writes accordingly.
The main use case of dm-clone is to clone a potentially remote, high-latency,
read-only, archival-type block device into a writable, fast, primary-type device
for fast, low-latency I/O. The cloned device is visible/mountable immediately
and the copy of the source device to the destination device happens in the
background, in parallel with user I/O.
For example, one could restore an application backup from a read-only copy,
accessible through a network storage protocol (NBD, Fibre Channel, iSCSI, AoE,
etc.), into a local SSD or NVMe device, and start using the device immediately,
without waiting for the restore to complete.
When the cloning completes, the dm-clone table can be removed altogether and be
replaced, e.g., by a linear table, mapping directly to the destination device.
The dm-clone target reuses the metadata library used by the thin-provisioning
target.
Glossary
========
Hydration
The process of filling a region of the destination device with data from
the same region of the source device, i.e., copying the region from the
source to the destination device.
Once a region gets hydrated we redirect all I/O regarding it to the destination
device.
Design
======
Sub-devices
-----------
The target is constructed by passing three devices to it (along with other
parameters detailed later):
1. A source device - the read-only device that gets cloned and source of the
hydration.
2. A destination device - the destination of the hydration, which will become a
clone of the source device.
3. A small metadata device - it records which regions are already valid in the
destination device, i.e., which regions have already been hydrated, or have
been written to directly, via user I/O.
The size of the destination device must be at least equal to the size of the
source device.
Regions
-------
dm-clone divides the source and destination devices in fixed sized regions.
Regions are the unit of hydration, i.e., the minimum amount of data copied from
the source to the destination device.
The region size is configurable when you first create the dm-clone device. The
recommended region size is the same as the file system block size, which usually
is 4KB. The region size must be between 8 sectors (4KB) and 2097152 sectors
(1GB) and a power of two.
Reads and writes from/to hydrated regions are serviced from the destination
device.
A read to a not yet hydrated region is serviced directly from the source device.
A write to a not yet hydrated region will be delayed until the corresponding
region has been hydrated and the hydration of the region starts immediately.
Note that a write request with size equal to region size will skip copying of
the corresponding region from the source device and overwrite the region of the
destination device directly.
Discards
--------
dm-clone interprets a discard request to a range that hasn't been hydrated yet
as a hint to skip hydration of the regions covered by the request, i.e., it
skips copying the region's data from the source to the destination device, and
only updates its metadata.
If the destination device supports discards, then by default dm-clone will pass
down discard requests to it.
Background Hydration
--------------------
dm-clone copies continuously from the source to the destination device, until
all of the device has been copied.
Copying data from the source to the destination device uses bandwidth. The user
can set a throttle to prevent more than a certain amount of copying occurring at
any one time. Moreover, dm-clone takes into account user I/O traffic going to
the devices and pauses the background hydration when there is I/O in-flight.
A message `hydration_threshold <#regions>` can be used to set the maximum number
of regions being copied, the default being 1 region.
dm-clone employs dm-kcopyd for copying portions of the source device to the
destination device. By default, we issue copy requests of size equal to the
region size. A message `hydration_batch_size <#regions>` can be used to tune the
size of these copy requests. Increasing the hydration batch size results in
dm-clone trying to batch together contiguous regions, so we copy the data in
batches of this many regions.
When the hydration of the destination device finishes, a dm event will be sent
to user space.
Updating on-disk metadata
-------------------------
On-disk metadata is committed every time a FLUSH or FUA bio is written. If no
such requests are made then commits will occur every second. This means the
dm-clone device behaves like a physical disk that has a volatile write cache. If
power is lost you may lose some recent writes. The metadata should always be
consistent in spite of any crash.
Target Interface
================
Constructor
-----------
::
clone <metadata dev> <destination dev> <source dev> <region size>
[<#feature args> [<feature arg>]* [<#core args> [<core arg>]*]]
================ ==============================================================
metadata dev Fast device holding the persistent metadata
destination dev The destination device, where the source will be cloned
source dev Read only device containing the data that gets cloned
region size The size of a region in sectors
#feature args Number of feature arguments passed
feature args no_hydration or no_discard_passdown
#core args An even number of arguments corresponding to key/value pairs
passed to dm-clone
core args Key/value pairs passed to dm-clone, e.g. `hydration_threshold
256`
================ ==============================================================
Optional feature arguments are:
==================== =========================================================
no_hydration Create a dm-clone instance with background hydration
disabled
no_discard_passdown Disable passing down discards to the destination device
==================== =========================================================
Optional core arguments are:
================================ ==============================================
hydration_threshold <#regions> Maximum number of regions being copied from
the source to the destination device at any
one time, during background hydration.
hydration_batch_size <#regions> During background hydration, try to batch
together contiguous regions, so we copy data
from the source to the destination device in
batches of this many regions.
================================ ==============================================
Status
------
::
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
<region size> <#hydrated regions>/<#total regions> <#hydrating regions>
<#feature args> <feature args>* <#core args> <core args>*
<clone metadata mode>
======================= =======================================================
metadata block size Fixed block size for each metadata block in sectors
#used metadata blocks Number of metadata blocks used
#total metadata blocks Total number of metadata blocks
region size Configurable region size for the device in sectors
#hydrated regions Number of regions that have finished hydrating
#total regions Total number of regions to hydrate
#hydrating regions Number of regions currently hydrating
#feature args Number of feature arguments to follow
feature args Feature arguments, e.g. `no_hydration`
#core args Even number of core arguments to follow
core args Key/value pairs for tuning the core, e.g.
`hydration_threshold 256`
clone metadata mode ro if read-only, rw if read-write
In serious cases where even a read-only mode is deemed
unsafe no further I/O will be permitted and the status
will just contain the string 'Fail'. If the metadata
mode changes, a dm event will be sent to user space.
======================= =======================================================
Messages
--------
`disable_hydration`
Disable the background hydration of the destination device.
`enable_hydration`
Enable the background hydration of the destination device.
`hydration_threshold <#regions>`
Set background hydration threshold.
`hydration_batch_size <#regions>`
Set background hydration batch size.
Examples
========
Clone a device containing a file system
---------------------------------------
1. Create the dm-clone device.
::
dmsetup create clone --table "0 1048576000 clone $metadata_dev $dest_dev \
$source_dev 8 1 no_hydration"
2. Mount the device and trim the file system. dm-clone interprets the discards
sent by the file system and it will not hydrate the unused space.
::
mount /dev/mapper/clone /mnt/cloned-fs
fstrim /mnt/cloned-fs
3. Enable background hydration of the destination device.
::
dmsetup message clone 0 enable_hydration
4. When the hydration finishes, we can replace the dm-clone table with a linear
table.
::
dmsetup suspend clone
dmsetup load clone --table "0 1048576000 linear $dest_dev 0"
dmsetup resume clone
The metadata device is no longer needed and can be safely discarded or reused
for other purposes.
Known issues
============
1. We redirect reads, to not-yet-hydrated regions, to the source device. If
reading the source device has high latency and the user repeatedly reads from
the same regions, this behaviour could degrade performance. We should use
these reads as hints to hydrate the relevant regions sooner. Currently, we
rely on the page cache to cache these regions, so we hopefully don't end up
reading them multiple times from the source device.
2. Release in-core resources, i.e., the bitmaps tracking which regions are
hydrated, after the hydration has finished.
3. During background hydration, if we fail to read the source or write to the
destination device, we print an error message, but the hydration process
continues indefinitely, until it succeeds. We should stop the background
hydration after a number of failures and emit a dm event for user space to
notice.
Why not...?
===========
We explored the following alternatives before implementing dm-clone:
1. Use dm-cache with cache size equal to the source device and implement a new
cloning policy:
* The resulting cache device is not a one-to-one mirror of the source device
and thus we cannot remove the cache device once cloning completes.
* dm-cache writes to the source device, which violates our requirement that
the source device must be treated as read-only.
* Caching is semantically different from cloning.
2. Use dm-snapshot with a COW device equal to the source device:
* dm-snapshot stores its metadata in the COW device, so the resulting device
is not a one-to-one mirror of the source device.
* No background copying mechanism.
* dm-snapshot needs to commit its metadata whenever a pending exception
completes, to ensure snapshot consistency. In the case of cloning, we don't
need to be so strict and can rely on committing metadata every time a FLUSH
or FUA bio is written, or periodically, like dm-thin and dm-cache do. This
improves the performance significantly.
3. Use dm-mirror: The mirror target has a background copying/mirroring
mechanism, but it writes to all mirrors, thus violating our requirement that
the source device must be treated as read-only.
4. Use dm-thin's external snapshot functionality. This approach is the most
promising among all alternatives, as the thinly-provisioned volume is a
one-to-one mirror of the source device and handles reads and writes to
un-provisioned/not-yet-cloned areas the same way as dm-clone does.
Still:
* There is no background copying mechanism, though one could be implemented.
* Most importantly, we want to support arbitrary block devices as the
destination of the cloning process and not restrict ourselves to
thinly-provisioned volumes. Thin-provisioning has an inherent metadata
overhead, for maintaining the thin volume mappings, which significantly
degrades performance.
Moreover, cloning a device shouldn't force the use of thin-provisioning. On
the other hand, if we wish to use thin provisioning, we can just use a thin
LV as dm-clone's destination device.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
즉시 사용 가능한 block-device clone
1-42`dm-clone`은 기존 read-only source device를 writable destination device에 one-to-one으로 복제하는 device-mapper target입니다. 모든 data가 즉시 보이는 virtual block device를 제공하고, clone 진행 상태에 따라 read와 write를 알맞은 device로 redirect합니다.
주요 용도는 remote·high-latency·read-only archival block device를 writable·fast primary device로 clone해 낮은 latency의 빠른 I/O를 제공하는 것입니다. Clone device는 즉시 보이고 mount할 수 있으며, source에서 destination으로의 copy는 user I/O와 병렬로 background에서 진행됩니다.
예를 들어 NBD, Fibre Channel, iSCSI, AoE 같은 network storage protocol로 접근하는 read-only application backup을 local SSD나 NVMe로 복원하면서 전체 restore 완료를 기다리지 않고 즉시 사용할 수 있습니다.
Cloning이 끝나면 dm-clone table을 완전히 제거하고 destination device를 직접 map하는 linear table 등으로 교체할 수 있습니다. dm-clone target은 thin-provisioning target이 사용하는 metadata library를 재사용합니다.
`Hydration`은 source device의 특정 region data로 destination device의 같은 region을 채우는 과정, 즉 그 region을 source에서 destination으로 copy하는 과정입니다. Region이 hydrated되면 해당 region의 모든 I/O를 destination device로 redirect합니다.
Virtual device는 즉시 열리고 region별 hydration이 background에서 진행됩니다.
Source, destination, metadata device
43-64Target은 뒤에서 설명할 parameter와 함께 세 device를 받아 구성합니다.
Read-only 원본, writable 복제본과 persistent hydration state를 분리합니다.
Region 단위 hydration과 I/O
65-88dm-clone은 source와 destination을 고정 크기 region으로 나눕니다. Region은 hydration 단위이며 source에서 destination으로 copy하는 최소 data 양입니다.
Region 크기는 dm-clone device를 처음 만들 때 설정합니다. File-system block 크기와 같은 값이 권장되며 보통 4KB입니다. 허용 범위는 8 sector(4KB)에서 `2097152` sector(1GB)이고 2의 거듭제곱이어야 합니다.
Hydrated region에 대한 read와 write는 destination device에서 처리합니다. 아직 hydrated되지 않은 region의 read는 source device에서 직접 처리합니다.
아직 hydrated되지 않은 region에 write하면 해당 region의 hydration을 즉시 시작하고 완료될 때까지 write를 지연합니다. 단, write request 크기가 region 크기와 정확히 같으면 source에서 해당 region을 copy하지 않고 destination region을 직접 덮어씁니다.
Hydration 여부와 full-region write 여부에 따라 data source가 달라집니다.
부분 write는 기존 source data가 필요한 나머지 region을 먼저 채웁니다.
Discard hint와 background hydration
89-123아직 hydrated되지 않은 범위에 대한 discard request는 해당 region의 hydration을 생략하라는 hint로 해석합니다. Source에서 destination으로 region data를 copy하지 않고 metadata만 갱신합니다.
Destination device가 discard를 지원하면 dm-clone은 기본적으로 discard request를 아래 device로 전달합니다.
dm-clone은 전체 device가 copy될 때까지 source에서 destination으로 계속 background copy합니다. 이 작업은 bandwidth를 사용하므로 동시에 copy하는 양을 throttle할 수 있습니다. 또한 device로 향하는 user I/O traffic을 고려해 in-flight I/O가 있으면 background hydration을 일시 중지합니다.
`hydration_threshold <#regions>` message는 동시에 copy할 최대 region 수를 정하며 기본값은 1 region입니다.
dm-clone은 source 일부를 destination으로 copy할 때 `dm-kcopyd`를 사용합니다. 기본 copy request 크기는 region 크기와 같습니다. `hydration_batch_size <#regions>` message로 크기를 조정할 수 있으며 값을 늘리면 연속 region을 묶어 지정한 region 수만큼 batch로 copy하려고 합니다.
Destination device의 hydration이 끝나면 user space로 dm event를 보냅니다.
사용하지 않는 unhydrated 영역은 data copy 없이 valid state만 갱신할 수 있습니다.
User I/O를 우선하고 threshold와 batch size로 copy pressure를 제어합니다.
On-disk metadata commit
124-132FLUSH 또는 FUA bio가 write될 때마다 on-disk metadata를 commit합니다. 그런 request가 없으면 1초마다 commit합니다.
따라서 dm-clone device는 volatile write cache가 있는 물리 disk처럼 동작합니다. 전원을 잃으면 최근 write 일부를 잃을 수 있지만 어떤 crash 뒤에도 metadata는 항상 일관된 상태여야 합니다.
명시적 durability request와 periodic commit을 함께 사용합니다.
Target constructor와 optional argument
133-178dm-clone target의 constructor 형식은 다음과 같습니다.
clone <metadata dev> <destination dev> <source dev> <region size>
[<#feature args> [<feature arg>]* [<#core args> [<core arg>]*]]Persistent state, destination, source와 region 크기를 지정합니다.
Background hydration과 discard 전달 여부를 제어합니다.
동시 copy 양과 contiguous batching을 조절합니다.
Status field와 runtime message
179-224Status는 metadata 사용량, region hydration 진행 상황, feature·core argument와 metadata mode를 다음 순서로 출력합니다.
<metadata block size> <#used metadata blocks>/<#total metadata blocks>
<region size> <#hydrated regions>/<#total regions> <#hydrating regions>
<#feature args> <feature args>* <#core args> <core args>*
<clone metadata mode>Status line에서 hydration 진행률과 metadata 안전 상태를 읽습니다.
Background hydration을 켜고 끄거나 copy pressure를 조정합니다.
File system이 있는 device clone
225-263첫 단계에서는 background hydration을 끈 상태로 dm-clone device를 만듭니다.
dmsetup create clone --table "0 1048576000 clone $metadata_dev $dest_dev \
$source_dev 8 1 no_hydration"두 번째 단계에서는 device를 mount하고 file system을 trim합니다. dm-clone은 file system이 보낸 discard를 해석해 사용하지 않는 공간을 hydrate하지 않습니다.
mount /dev/mapper/clone /mnt/cloned-fs
fstrim /mnt/cloned-fs세 번째 단계에서는 destination의 background hydration을 활성화합니다.
dmsetup message clone 0 enable_hydrationHydration이 끝나면 dm-clone table을 destination을 직접 가리키는 linear table로 교체할 수 있습니다.
dmsetup suspend clone
dmsetup load clone --table "0 1048576000 linear $dest_dev 0"
dmsetup resume clone이 시점부터 metadata device는 필요하지 않으므로 안전하게 버리거나 다른 목적으로 재사용할 수 있습니다.
Unused space를 trim으로 제외한 뒤 background copy를 완료하고 linear mapping으로 전환합니다.
현재 알려진 한계
264-282아직 hydrated되지 않은 region의 read는 source device로 redirect합니다. Source latency가 높고 같은 region을 반복해서 읽으면 성능이 떨어질 수 있습니다. 이런 read를 해당 region의 hydration 우선순위를 높이는 hint로 사용해야 합니다. 현재는 page cache가 region을 cache해 source에서 여러 번 읽지 않기를 기대합니다.
Hydration이 끝난 뒤에는 어떤 region이 hydrated됐는지 추적하는 bitmap 같은 in-core resource를 해제해야 합니다.
Background hydration 중 source read나 destination write가 실패하면 error message를 출력하지만 성공할 때까지 무기한 계속 시도합니다. 일정 횟수 실패 뒤 background hydration을 멈추고 user space가 알아차릴 수 있도록 dm event를 보내야 합니다.
현재 동작이 만드는 비용과 문서가 제안하는 개선 방향입니다.
다른 DM target을 사용하지 않은 이유
283-333dm-clone을 구현하기 전에 dm-cache, dm-snapshot, dm-mirror, dm-thin external snapshot을 대안으로 검토했습니다.
One-to-one clone, read-only source, background copy와 destination 범용성 요구를 기준으로 비교합니다.
dm-snapshot은 pending exception이 끝날 때마다 metadata를 commit해 snapshot consistency를 보장합니다. Cloning에는 그 정도로 엄격할 필요가 없으므로 dm-thin과 dm-cache처럼 FLUSH/FUA bio 또는 periodic commit에 의존할 수 있고, 이것이 성능을 크게 높입니다.
dm-thin external snapshot은 대안 중 가장 유망합니다. Thinly-provisioned volume은 source의 one-to-one mirror이고 아직 provision 또는 clone되지 않은 영역의 read/write를 dm-clone과 같은 방식으로 처리합니다. Background copy도 구현할 수 있습니다.
하지만 clone destination으로 임의의 block device를 지원해야 하며 thinly-provisioned volume으로 제한하고 싶지 않습니다. Thin-provisioning의 mapping metadata overhead는 성능을 크게 낮춥니다. Device clone이 thin-provisioning 사용을 강제해서도 안 됩니다. Thin provisioning이 필요하다면 thin LV를 dm-clone의 destination device로 사용하면 됩니다.
Region hydration 설계
dm-clone.rst:1-132Source·destination·metadata device, region별 I/O routing, discard hint와 background copy 및 metadata commit 모델을 정리합니다.