요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Operations
vdo.rst:192-335생성·확장 예제, device message와 status field, capacity별 RAM 요구량을 다룹니다.
Runtime and tuning
vdo.rst:336-413Shared block·thin provisioning의 운영 특성과 cache, zone thread, submission·ack·CPU·hash thread tuning 기준을 설명합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0-only
======
dm-vdo
======
The dm-vdo (virtual data optimizer) device mapper target provides
block-level deduplication, compression, and thin provisioning. As a device
mapper target, it can add these features to the storage stack, compatible
with any file system. The vdo target does not protect against data
corruption, relying instead on integrity protection of the storage below
it. It is strongly recommended that lvm be used to manage vdo volumes. See
lvmvdo(7).
Userspace component
===================
Formatting a vdo volume requires the use of the 'vdoformat' tool, available
at:
https://github.com/dm-vdo/vdo/
In most cases, a vdo target will recover from a crash automatically the
next time it is started. In cases where it encountered an unrecoverable
error (either during normal operation or crash recovery) the target will
enter or come up in read-only mode. Because read-only mode is indicative of
data-loss, a positive action must be taken to bring vdo out of read-only
mode. The 'vdoforcerebuild' tool, available from the same repo, is used to
prepare a read-only vdo to exit read-only mode. After running this tool,
the vdo target will rebuild its metadata the next time it is
started. Although some data may be lost, the rebuilt vdo's metadata will be
internally consistent and the target will be writable again.
The repo also contains additional userspace tools which can be used to
inspect a vdo target's on-disk metadata. Fortunately, these tools are
rarely needed except by dm-vdo developers.
Metadata requirements
=====================
Each vdo volume reserves 3GB of space for metadata, or more depending on
its configuration. It is helpful to check that the space saved by
deduplication and compression is not cancelled out by the metadata
requirements. An estimation of the space saved for a specific dataset can
be computed with the vdo estimator tool, which is available at:
https://github.com/dm-vdo/vdoestimator/
Target interface
================
Table line
----------
::
<offset> <logical device size> vdo V4 <storage device>
<storage device size> <minimum I/O size> <block map cache size>
<block map era length> [optional arguments]
Required parameters:
offset:
The offset, in sectors, at which the vdo volume's logical
space begins.
logical device size:
The size of the device which the vdo volume will service,
in sectors. Must match the current logical size of the vdo
volume.
storage device:
The device holding the vdo volume's data and metadata.
storage device size:
The size of the device holding the vdo volume, as a number
of 4096-byte blocks. Must match the current size of the vdo
volume.
minimum I/O size:
The minimum I/O size for this vdo volume to accept, in
bytes. Valid values are 512 or 4096. The recommended value
is 4096.
block map cache size:
The size of the block map cache, as a number of 4096-byte
blocks. The minimum and recommended value is 32768 blocks.
If the logical thread count is non-zero, the cache size
must be at least 4096 blocks per logical thread.
block map era length:
The speed with which the block map cache writes out
modified block map pages. A smaller era length is likely to
reduce the amount of time spent rebuilding, at the cost of
increased block map writes during normal operation. The
maximum and recommended value is 16380; the minimum value
is 1.
Optional parameters:
--------------------
Some or all of these parameters may be specified as <key> <value> pairs.
Thread related parameters:
Different categories of work are assigned to separate thread groups, and
the number of threads in each group can be configured separately.
If <hash>, <logical>, and <physical> are all set to 0, the work handled by
all three thread types will be handled by a single thread. If any of these
values are non-zero, all of them must be non-zero.
ack:
The number of threads used to complete bios. Since
completing a bio calls an arbitrary completion function
outside the vdo volume, threads of this type allow the vdo
volume to continue processing requests even when bio
completion is slow. The default is 1.
bio:
The number of threads used to issue bios to the underlying
storage. Threads of this type allow the vdo volume to
continue processing requests even when bio submission is
slow. The default is 4.
bioRotationInterval:
The number of bios to enqueue on each bio thread before
switching to the next thread. The value must be greater
than 0 and not more than 1024; the default is 64.
cpu:
The number of threads used to do CPU-intensive work, such
as hashing and compression. The default is 1.
hash:
The number of threads used to manage data comparisons for
deduplication based on the hash value of data blocks. The
default is 0.
logical:
The number of threads used to manage caching and locking
based on the logical address of incoming bios. The default
is 0; the maximum is 60.
physical:
The number of threads used to manage administration of the
underlying storage device. At format time, a slab size for
the vdo is chosen; the vdo storage device must be large
enough to have at least 1 slab per physical thread. The
default is 0; the maximum is 16.
Miscellaneous parameters:
maxDiscard:
The maximum size of discard bio accepted, in 4096-byte
blocks. I/O requests to a vdo volume are normally split
into 4096-byte blocks, and processed up to 2048 at a time.
However, discard requests to a vdo volume can be
automatically split to a larger size, up to <maxDiscard>
4096-byte blocks in a single bio, and are limited to 1500
at a time. Increasing this value may provide better overall
performance, at the cost of increased latency for the
individual discard requests. The default and minimum is 1;
the maximum is UINT_MAX / 4096.
deduplication:
Whether deduplication is enabled. The default is 'on'; the
acceptable values are 'on' and 'off'.
compression:
Whether compression is enabled. The default is 'off'; the
acceptable values are 'on' and 'off'.
Device modification
-------------------
A modified table may be loaded into a running, non-suspended vdo volume.
The modifications will take effect when the device is next resumed. The
modifiable parameters are <logical device size>, <physical device size>,
<maxDiscard>, <compression>, and <deduplication>.
If the logical device size or physical device size are changed, upon
successful resume vdo will store the new values and require them on future
startups. These two parameters may not be decreased. The logical device
size may not exceed 4 PB. The physical device size must increase by at
least 32832 4096-byte blocks if at all, and must not exceed the size of the
underlying storage device. Additionally, when formatting the vdo device, a
slab size is chosen: the physical device size may never increase above the
size which provides 8192 slabs, and each increase must be large enough to
add at least one new slab.
Examples:
Start a previously-formatted vdo volume with 1 GB logical space and 1 GB
physical space, storing to /dev/dm-1 which has more than 1 GB of space.
::
dmsetup create vdo0 --table \
"0 2097152 vdo V4 /dev/dm-1 262144 4096 32768 16380"
Grow the logical size to 4 GB.
::
dmsetup reload vdo0 --table \
"0 8388608 vdo V4 /dev/dm-1 262144 4096 32768 16380"
dmsetup resume vdo0
Grow the physical size to 2 GB.
::
dmsetup reload vdo0 --table \
"0 8388608 vdo V4 /dev/dm-1 524288 4096 32768 16380"
dmsetup resume vdo0
Grow the physical size by 1 GB more and increase max discard sectors.
::
dmsetup reload vdo0 --table \
"0 10485760 vdo V4 /dev/dm-1 786432 4096 32768 16380 maxDiscard 8"
dmsetup resume vdo0
Stop the vdo volume.
::
dmsetup remove vdo0
Start the vdo volume again. Note that the logical and physical device sizes
must still match, but other parameters can change.
::
dmsetup create vdo1 --table \
"0 10485760 vdo V4 /dev/dm-1 786432 512 65550 5000 hash 1 logical 3 physical 2"
Messages
--------
All vdo devices accept messages in the form:
::
dmsetup message <target-name> 0 <message-name> <message-parameters>
The messages are:
stats:
Outputs the current view of the vdo statistics. Mostly used
by the vdostats userspace program to interpret the output
buffer.
config:
Outputs useful vdo configuration information. Mostly used
by users who want to recreate a similar VDO volume and
want to know the creation configuration used.
dump:
Dumps many internal structures to the system log. This is
not always safe to run, so it should only be used to debug
a hung vdo. Optional parameters to specify structures to
dump are:
viopool: The pool of I/O requests incoming bios
pools: A synonym of 'viopool'
vdo: Most of the structures managing on-disk data
queues: Basic information about each vdo thread
threads: A synonym of 'queues'
default: Equivalent to 'queues vdo'
all: All of the above.
dump-on-shutdown:
Perform a default dump next time vdo shuts down.
Status
------
::
<device> <operating mode> <in recovery> <index state>
<compression state> <physical blocks used> <total physical blocks>
device:
The name of the vdo volume.
operating mode:
The current operating mode of the vdo volume; values may be
'normal', 'recovering' (the volume has detected an issue
with its metadata and is attempting to repair itself), and
'read-only' (an error has occurred that forces the vdo
volume to only support read operations and not writes).
in recovery:
Whether the vdo volume is currently in recovery mode;
values may be 'recovering' or '-' which indicates not
recovering.
index state:
The current state of the deduplication index in the vdo
volume; values may be 'closed', 'closing', 'error',
'offline', 'online', 'opening', and 'unknown'.
compression state:
The current state of compression in the vdo volume; values
may be 'offline' and 'online'.
used physical blocks:
The number of physical blocks in use by the vdo volume.
total physical blocks:
The total number of physical blocks the vdo volume may use;
the difference between this value and the
<used physical blocks> is the number of blocks the vdo
volume has left before being full.
Memory Requirements
===================
A vdo target requires a fixed 38 MB of RAM along with the following amounts
that scale with the target:
- 1.15 MB of RAM for each 1 MB of configured block map cache size. The
block map cache requires a minimum of 150 MB.
- 1.6 MB of RAM for each 1 TB of logical space.
- 268 MB of RAM for each 1 TB of physical storage managed by the volume.
The deduplication index requires additional memory which scales with the
size of the deduplication window. For dense indexes, the index requires 1
GB of RAM per 1 TB of window. For sparse indexes, the index requires 1 GB
of RAM per 10 TB of window. The index configuration is set when the target
is formatted and may not be modified.
Module Parameters
=================
The vdo driver has a numeric parameter 'log_level' which controls the
verbosity of logging from the driver. The default setting is 6
(LOGLEVEL_INFO and more severe messages).
Run-time Usage
==============
When using dm-vdo, it is important to be aware of the ways in which its
behavior differs from other storage targets.
- There is no guarantee that over-writes of existing blocks will succeed.
Because the underlying storage may be multiply referenced, over-writing
an existing block generally requires a vdo to have a free block
available.
- When blocks are no longer in use, sending a discard request for those
blocks lets the vdo release references for those blocks. If the vdo is
thinly provisioned, discarding unused blocks is essential to prevent the
target from running out of space. However, due to the sharing of
duplicate blocks, no discard request for any given logical block is
guaranteed to reclaim space.
- Assuming the underlying storage properly implements flush requests, vdo
is resilient against crashes, however, unflushed writes may or may not
persist after a crash.
- Each write to a vdo target entails a significant amount of processing.
However, much of the work is paralellizable. Therefore, vdo targets
achieve better throughput at higher I/O depths, and can support up 2048
requests in parallel.
Tuning
======
The vdo device has many options, and it can be difficult to make optimal
choices without perfect knowledge of the workload. Additionally, most
configuration options must be set when a vdo target is started, and cannot
be changed without shutting it down completely; the configuration cannot be
changed while the target is active. Ideally, tuning with simulated
workloads should be performed before deploying vdo in production
environments.
The most important value to adjust is the block map cache size. In order to
service a request for any logical address, a vdo must load the portion of
the block map which holds the relevant mapping. These mappings are cached.
Performance will suffer when the working set does not fit in the cache. By
default, a vdo allocates 128 MB of metadata cache in RAM to support
efficient access to 100 GB of logical space at a time. It should be scaled
up proportionally for larger working sets.
The logical and physical thread counts should also be adjusted. A logical
thread controls a disjoint section of the block map, so additional logical
threads increase parallelism and can increase throughput. Physical threads
control a disjoint section of the data blocks, so additional physical
threads can also increase throughput. However, excess threads can waste
resources and increase contention.
Bio submission threads control the parallelism involved in sending I/O to
the underlying storage; fewer threads mean there is more opportunity to
reorder I/O requests for performance benefit, but also that each I/O
request has to wait longer before being submitted.
Bio acknowledgment threads are used for finishing I/O requests. This is
done on dedicated threads since the amount of work required to execute a
bio's callback can not be controlled by the vdo itself. Usually one thread
is sufficient but additional threads may be beneficial, particularly when
bios have CPU-heavy callbacks.
CPU threads are used for hashing and for compression; in workloads with
compression enabled, more threads may result in higher throughput.
Hash threads are used to sort active requests by hash and determine whether
they should deduplicate; the most CPU intensive actions done by these
threads are comparison of 4096-byte data blocks. In most cases, a single
hash thread is sufficient.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
dm-vdo와 userspace 도구
1-37`dm-vdo`(virtual data optimizer) device-mapper target은 block-level deduplication, compression, thin provisioning을 제공합니다. Device-mapper target이므로 모든 file system과 호환되면서 storage stack에 이 기능을 추가할 수 있습니다.
vdo target 자체는 data corruption을 방지하지 않으며 아래 storage 계층의 integrity protection에 의존합니다. vdo volume 관리는 LVM을 사용하는 것을 강력히 권장합니다. `lvmvdo(7)`를 참조하십시오.
vdo volume을 format하려면 다음 저장소에서 제공하는 `vdoformat` 도구가 필요합니다: `https://github.com/dm-vdo/vdo/`.
대부분의 경우 vdo target은 crash 뒤 다음 시작 때 자동으로 복구합니다. 정상 동작 또는 crash recovery 중 복구할 수 없는 error를 만나면 target은 read-only mode로 들어가거나 그 mode로 시작합니다. Read-only mode는 data loss를 의미하므로 이를 벗어나려면 명시적인 조치가 필요합니다.
같은 저장소의 `vdoforcerebuild` 도구는 read-only vdo가 이 mode를 벗어나도록 준비합니다. 도구 실행 후 다음 시작 때 vdo target이 metadata를 rebuild합니다. Data 일부를 잃을 수 있지만 rebuild된 metadata는 내부적으로 일관되고 target은 다시 writable 상태가 됩니다.
저장소에는 vdo target의 on-disk metadata를 검사하는 추가 userspace 도구도 있습니다. 다행히 dm-vdo developer 외에는 이런 도구가 필요한 경우가 드뭅니다.
Data loss 가능성이 있으므로 rebuild는 자동으로 수행되지 않습니다.
Metadata와 필수 table parameter
38-99각 vdo volume은 metadata용으로 3GB 이상을 예약하며 정확한 양은 configuration에 따라 늘어납니다. Deduplication과 compression으로 절약한 공간이 metadata 요구량 때문에 상쇄되지 않는지 확인하는 것이 좋습니다. 특정 dataset의 예상 절약량은 `https://github.com/dm-vdo/vdoestimator/`의 vdo estimator 도구로 계산할 수 있습니다.
Target table line 형식은 다음과 같습니다.
::
<offset> <logical device size> vdo V4 <storage device>
<storage device size> <minimum I/O size> <block map cache size>
<block map era length> [optional arguments]Sector 단위와 4096-byte block 단위가 섞이므로 각 parameter 단위를 구분해야 합니다.
`offset`은 vdo volume의 logical space가 시작하는 sector offset입니다. `logical device size`는 vdo volume이 service할 device의 sector 수이며 현재 volume logical size와 반드시 일치해야 합니다. `storage device`는 volume data와 metadata를 보관하는 device입니다.
`storage device size`는 vdo volume을 담는 device의 크기를 4096-byte block 수로 나타내며 현재 vdo volume size와 일치해야 합니다. `minimum I/O size`는 volume이 받을 최소 byte 수로 512와 4096만 유효하며 4096을 권장합니다.
`block map cache size`는 4096-byte block 수로 표현합니다. 최소값이자 권장값은 32768 block입니다. Logical thread count가 0이 아니면 logical thread마다 최소 4096 block이 필요합니다.
`block map era length`는 block map cache가 수정된 block map page를 기록하는 속도를 결정합니다. 값이 작으면 정상 동작 중 block map write가 늘어나는 대신 rebuild 시간이 줄어들 가능성이 큽니다. 최대값이자 권장값은 16380이고 최소값은 1입니다.
Optional thread parameter
100-151Optional parameter는 일부 또는 전부를 `<key> <value>` 쌍으로 지정할 수 있습니다. 서로 다른 작업 category는 별도 thread group에 배정되며 group별 thread 수를 독립적으로 구성할 수 있습니다.
`hash`, `logical`, `physical`이 모두 0이면 세 thread type의 작업을 단일 thread가 처리합니다. 이 값 중 하나라도 0이 아니면 세 값 모두 0이 아니어야 합니다.
I/O completion·submission, CPU work와 세 zone owner group을 조정합니다.
`ack`는 bio 완료에 사용하는 thread 수입니다. Bio completion은 vdo volume 밖의 임의 completion function을 호출하므로 callback이 느려도 volume이 request 처리를 계속할 수 있게 합니다. 기본값은 1입니다.
`bio`는 underlying storage에 bio를 발행하는 thread 수입니다. Bio submission이 느려도 volume이 request 처리를 계속하게 하며 기본값은 4입니다. `bioRotationInterval`은 다음 bio thread로 전환하기 전에 각 thread에 enqueue할 bio 수입니다. 0보다 크고 1024 이하여야 하며 기본값은 64입니다.
`cpu`는 hashing과 compression 같은 CPU-intensive work에 쓰는 thread 수이며 기본값은 1입니다. `hash`는 data block hash value에 따라 deduplication용 data comparison을 관리하는 thread 수이며 기본값은 0입니다.
`logical`은 incoming bio의 logical address를 기준으로 caching과 locking을 관리하는 thread 수입니다. 기본값은 0이고 최대값은 60입니다.
`physical`은 underlying storage device 관리를 담당하는 thread 수입니다. Format 때 vdo slab size가 결정되며 storage device에는 physical thread마다 최소 slab 하나가 있을 만큼 공간이 있어야 합니다. 기본값은 0이고 최대값은 16입니다.
Discard·최적화 option과 device 변경
152-191`maxDiscard`는 vdo가 받을 discard bio의 최대 크기를 4096-byte block 수로 지정합니다. 일반 I/O request는 보통 4096-byte block으로 분할되어 한 번에 최대 2048개를 처리합니다. 그러나 discard request는 단일 bio에서 최대 `<maxDiscard>`개의 4096-byte block까지 더 크게 자동 분할할 수 있고 동시에 처리하는 수는 1500개로 제한됩니다.
`maxDiscard`를 늘리면 개별 discard request latency가 증가하는 대신 전체 성능이 좋아질 수 있습니다. 기본값이자 최소값은 1이고 최대값은 `UINT_MAX / 4096`입니다.
`deduplication`은 deduplication 활성화 여부이며 기본값은 `on`, 허용값은 `on`과 `off`입니다. `compression`은 compression 활성화 여부이며 기본값은 `off`, 허용값은 `on`과 `off`입니다.
실행 중이며 suspend되지 않은 vdo volume에 수정된 table을 load할 수 있습니다. 변경은 device를 다음에 resume할 때 적용됩니다. 수정 가능한 parameter는 `logical device size`, `physical device size`, `maxDiscard`, `compression`, `deduplication`입니다.
Logical 또는 physical device size를 변경하고 resume이 성공하면 vdo는 새 값을 저장하고 이후 시작 때 그 값을 요구합니다. 두 size는 줄일 수 없으며 logical device size는 4PB를 넘을 수 없습니다.
Physical device size는 변경한다면 최소 32832개의 4096-byte block만큼 늘려야 하고 underlying storage device size를 넘을 수 없습니다. Format 때 slab size가 정해지므로 physical size는 slab 8192개를 제공하는 크기를 넘을 수 없고, 각 증가는 새 slab을 최소 하나 추가할 만큼 커야 합니다.
Reload 뒤 resume할 때 적용되며 size 증가는 persistent contract가 됩니다.
생성·확장·재시작 예제
192-2391GB보다 큰 `/dev/dm-1`에 저장하면서 logical space와 physical space가 각각 1GB인, 미리 format된 vdo volume을 시작합니다.
::
dmsetup create vdo0 --table \
"0 2097152 vdo V4 /dev/dm-1 262144 4096 32768 16380"Logical size를 4GB로 확장합니다.
::
dmsetup reload vdo0 --table \
"0 8388608 vdo V4 /dev/dm-1 262144 4096 32768 16380"
dmsetup resume vdo0Physical size를 2GB로 확장합니다.
::
dmsetup reload vdo0 --table \
"0 8388608 vdo V4 /dev/dm-1 524288 4096 32768 16380"
dmsetup resume vdo0Physical size를 1GB 더 늘리고 maximum discard sector도 증가시킵니다.
::
dmsetup reload vdo0 --table \
"0 10485760 vdo V4 /dev/dm-1 786432 4096 32768 16380 maxDiscard 8"
dmsetup resume vdo0vdo volume을 중지합니다.
::
dmsetup remove vdo0vdo volume을 다시 시작합니다. Logical·physical device size는 저장된 값과 계속 일치해야 하지만 다른 parameter는 바꿀 수 있습니다.
::
dmsetup create vdo1 --table \
"0 10485760 vdo V4 /dev/dm-1 786432 512 65550 5000 hash 1 logical 3 physical 2"Size를 늘리는 table을 reload하고 resume하여 새 persistent geometry를 확정합니다.
Device message
240-277모든 vdo device는 다음 형식의 message를 받습니다.
::
dmsetup message <target-name> 0 <message-name> <message-parameters>상태 조회와 debugging dump를 target message interface로 요청합니다.
`stats`는 vdo statistics의 현재 view를 출력하며 주로 `vdostats` userspace program이 output buffer를 해석할 때 사용합니다. `config`는 유용한 vdo configuration 정보를 출력하며 같은 형태의 VDO volume을 재현하기 위해 사용된 creation configuration을 알고 싶은 사용자에게 유용합니다.
`dump`는 많은 internal structure를 system log에 출력합니다. 항상 안전한 작업은 아니므로 멈춘 vdo를 debug할 때만 사용해야 합니다.
선택 가능한 dump structure는 `viopool`(incoming bio I/O request pool), 그 동의어 `pools`, on-disk data를 관리하는 대부분의 structure인 `vdo`, 각 vdo thread 기본 정보인 `queues`, 그 동의어 `threads`, `queues vdo`와 같은 `default`, 위 항목 전체인 `all`입니다.
`dump-on-shutdown`은 다음 vdo shutdown 때 default dump를 수행하게 합니다.
Target status 형식
278-318Status line 형식은 다음과 같습니다.
::
<device> <operating mode> <in recovery> <index state>
<compression state> <physical blocks used> <total physical blocks>`device`는 vdo volume 이름입니다. `operating mode`는 현재 동작 mode로 `normal`, metadata 문제를 감지해 자체 repair를 시도하는 `recovering`, error 때문에 read만 지원하고 write를 막는 `read-only` 중 하나입니다.
`in recovery`는 현재 recovery mode인지 나타내며 값은 `recovering` 또는 recovery 중이 아님을 뜻하는 `-`입니다.
`index state`는 deduplication index의 현재 상태이며 `closed`, `closing`, `error`, `offline`, `online`, `opening`, `unknown` 중 하나입니다. `compression state`는 compression의 현재 상태이며 `offline` 또는 `online`입니다.
`used physical blocks`는 volume이 사용하는 physical block 수입니다. `total physical blocks`는 volume이 사용할 수 있는 총 physical block 수입니다. Total에서 used를 뺀 값이 volume이 가득 차기 전에 남은 block 수입니다.
Operating state, recovery/index/compression state와 capacity를 한 line에 제공합니다.
RAM 요구량
319-335vdo target에는 고정 38MB RAM과 target 규모에 따라 증가하는 다음 memory가 필요합니다.
구성한 block map cache 1MB마다 RAM 1.15MB가 필요하며 block map cache 자체는 최소 150MB가 필요합니다. Logical space 1TB마다 RAM 1.6MB, volume이 관리하는 physical storage 1TB마다 RAM 268MB가 필요합니다.
Deduplication index에는 deduplication window 크기에 비례하는 추가 memory가 필요합니다. Dense index는 window 1TB마다 RAM 1GB, sparse index는 window 10TB마다 RAM 1GB가 필요합니다. Index configuration은 target format 때 설정하며 변경할 수 없습니다.
고정 비용, cache와 logical·physical capacity, index window 비용을 합산합니다.
Module parameter와 run-time 특성
336-369vdo driver의 numeric module parameter `log_level`은 driver logging verbosity를 제어합니다. 기본값은 6으로 `LOGLEVEL_INFO`와 그보다 심각한 message를 출력합니다.
dm-vdo 사용 시 다른 storage target과 다른 동작을 이해해야 합니다.
기존 block overwrite가 성공한다고 보장할 수 없습니다. Underlying storage가 여러 logical block에서 함께 참조될 수 있으므로 기존 block을 overwrite하려면 일반적으로 vdo에 free block이 하나 있어야 합니다.
더는 사용하지 않는 block에 discard request를 보내면 vdo가 그 block의 reference를 해제할 수 있습니다. Thin provisioning 환경에서는 target의 공간 고갈을 막기 위해 unused block discard가 필수적입니다. 그러나 duplicate block 공유 때문에 특정 logical block의 discard가 실제 공간을 회수한다고 보장할 수 없습니다.
Underlying storage가 flush request를 올바르게 구현한다면 vdo는 crash에 견딜 수 있습니다. 다만 flush되지 않은 write는 crash 후 남을 수도 있고 사라질 수도 있습니다.
vdo target에 write할 때마다 상당한 처리가 필요하지만 많은 작업은 parallel하게 수행할 수 있습니다. 따라서 I/O depth가 높을수록 throughput이 좋아지며 최대 2048 request를 동시에 지원할 수 있습니다.
Thin provisioning과 shared physical block이 일반 block target과 다른 결과를 만듭니다.
Workload별 tuning
370-413vdo device에는 option이 많아 workload를 정확히 알지 못하면 최적값을 고르기 어렵습니다. 대부분의 configuration option은 target start 때 정해야 하고 완전히 shutdown하지 않으면 바꿀 수 없으며 target이 active인 동안은 configuration을 변경할 수 없습니다. Production 배포 전에 simulated workload로 tuning하는 것이 이상적입니다.
가장 중요한 조정값은 block map cache size입니다. 임의 logical address request를 처리하려면 해당 mapping이 든 block map 부분을 load해야 하며 이 mapping을 cache합니다. Working set이 cache에 맞지 않으면 성능이 저하됩니다. 기본적으로 vdo는 한 번에 100GB logical space에 효율적으로 접근하도록 RAM에 128MB metadata cache를 할당합니다. 더 큰 working set에는 비례해서 늘려야 합니다.
Logical·physical thread count도 조정해야 합니다. Logical thread는 block map의 서로 겹치지 않는 section을 제어하므로 thread를 추가하면 parallelism과 throughput이 증가할 수 있습니다. Physical thread는 data block의 서로 겹치지 않는 section을 제어하므로 역시 throughput을 높일 수 있습니다. 그러나 thread가 지나치면 resource를 낭비하고 contention이 증가합니다.
Bio submission thread는 underlying storage로 I/O를 보내는 parallelism을 제어합니다. Thread가 적으면 성능을 위해 I/O request를 reorder할 기회가 많지만 각 request가 제출되기 전 더 오래 기다립니다.
Bio acknowledgment thread는 I/O request를 완료합니다. Bio callback 실행에 필요한 작업량을 vdo가 제어할 수 없으므로 전용 thread에서 수행합니다. 보통 하나면 충분하지만 bio callback이 CPU-heavy하면 추가 thread가 유용할 수 있습니다.
CPU thread는 hashing과 compression에 사용됩니다. Compression을 활성화한 workload에서는 thread를 늘리면 throughput이 높아질 수 있습니다.
Hash thread는 active request를 hash로 정렬하고 deduplicate 여부를 판단합니다. 가장 CPU-intensive한 작업은 4096-byte data block 비교입니다. 대부분의 경우 hash thread 하나면 충분합니다.
먼저 working set cache를 맞춘 뒤 workload bottleneck에 따라 thread group을 조정합니다.
Target interface
vdo.rst:1-191Userspace 도구와 metadata 비용, 필수 table parameter 및 thread·discard·resize 제약을 단위와 범위 중심으로 정리합니다.