← Documents Documentation/admin-guide/device-mapper/era.rst GitHub 원문 ↗

Linux 6.18.37 · Administration / Device Mapper

dm-era

단조 증가 era별 changed block을 추적해 incremental backup과 snapshot rollback 후 cache invalidation을 지원합니다.

Source pathDocumentation/admin-guide/device-mapper/era.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

Era 추적 모델

era.rst:1-29

Changed-block counter, use case와 constructor granularity를 설명합니다.

Message, status와 workflow

era.rst:30-93

Checkpoint·metadata snapshot과 vendor rollback 절차를 정리합니다.

Memory와 crash resilience

era.rst:94-116

Bitset 비용, metadata-first write ordering과 userspace 도구를 설명합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 ======
2 dm-era
3 ======
4
5 Introduction
6 ============
7
8 dm-era is a target that behaves similar to the linear target. In
9 addition it keeps track of which blocks were written within a user
10 defined period of time called an 'era'. Each era target instance
11 maintains the current era as a monotonically increasing 32-bit
12 counter.
13
14 Use cases include tracking changed blocks for backup software, and
15 partially invalidating the contents of a cache to restore cache
16 coherency after rolling back a vendor snapshot.
17
18 Constructor
19 ===========
20
21 era <metadata dev> <origin dev> <block size>
22
23 ================ ======================================================
24 metadata dev fast device holding the persistent metadata
25 origin dev device holding data blocks that may change
26 block size block size of origin data device, granularity that is
27 tracked by the target
28 ================ ======================================================
29
30 Messages
31 ========
32
33 None of the dm messages take any arguments.
34
35 checkpoint
36 ----------
37
38 Possibly move to a new era. You shouldn't assume the era has
39 incremented. After sending this message, you should check the
40 current era via the status line.
41
42 take_metadata_snap
43 ------------------
44
45 Create a clone of the metadata, to allow a userland process to read it.
46
47 drop_metadata_snap
48 ------------------
49
50 Drop the metadata snapshot.
51
52 Status
53 ======
54
55 <metadata block size> <#used metadata blocks>/<#total metadata blocks>
56 <current era> <held metadata root | '-'>
57
58 ========================= ==============================================
59 metadata block size Fixed block size for each metadata block in
60 sectors
61 #used metadata blocks Number of metadata blocks used
62 #total metadata blocks Total number of metadata blocks
63 current era The current era
64 held metadata root The location, in blocks, of the metadata root
65 that has been 'held' for userspace read
66 access. '-' indicates there is no held root
67 ========================= ==============================================
68
69 Detailed use case
70 =================
71
72 The scenario of invalidating a cache when rolling back a vendor
73 snapshot was the primary use case when developing this target:
74
75 Taking a vendor snapshot
76 ------------------------
77
78 - Send a checkpoint message to the era target
79 - Make a note of the current era in its status line
80 - Take vendor snapshot (the era and snapshot should be forever
81 associated now).
82
83 Rolling back to an vendor snapshot
84 ----------------------------------
85
86 - Cache enters passthrough mode (see: dm-cache's docs in cache.txt)
87 - Rollback vendor storage
88 - Take metadata snapshot
89 - Ascertain which blocks have been written since the snapshot was taken
90 by checking each block's era
91 - Invalidate those blocks in the caching software
92 - Cache returns to writeback/writethrough mode
93
94 Memory usage
95 ============
96
97 The target uses a bitset to record writes in the current era. It also
98 has a spare bitset ready for switching over to a new era. Other than
99 that it uses a few 4k blocks for updating metadata::
100
101 (4 * nr_blocks) bytes + buffers
102
103 Resilience
104 ==========
105
106 Metadata is updated on disk before a write to a previously unwritten
107 block is performed. As such dm-era should not be effected by a hard
108 crash such as power failure.
109
110 Userland tools
111 ==============
112
113 Userland tools are found in the increasingly poorly named
114 thin-provisioning-tools project:
115
116 https://github.com/jthornber/thin-provisioning-tools
117

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

시간 구간별 changed-block 추적

1-17

`dm-era`는 linear target과 비슷하게 동작하면서 사용자가 정의한 `era`라는 기간 안에 어떤 block이 write됐는지 추적합니다. 각 target instance는 현재 era를 단조 증가하는 32-bit counter로 유지합니다.

Era 기반 write 추적
Era N 시작Block writes를 bitset에 기록Checkpoint 요청조건이 충족되면 era 증가Era N+1 writes 추적

Checkpoint 사이의 write를 하나의 시대 번호와 연결합니다.

주요 용도는 backup software가 변경 block을 추적하는 것과, vendor snapshot을 rollback한 뒤 cache 일관성을 복구하기 위해 cache 내용 일부를 invalidate하는 것입니다.

대표 use case
Use caseEra 정보 활용
Incremental backup이전 checkpoint 이후 write된 block 식별
Snapshot rollbackSnapshot 이후 바뀐 cache block만 invalidate

Block별 마지막 write era를 이용하는 두 작업입니다.

Metadata·origin device와 추적 granularity

18-29

Constructor 형식은 metadata device, origin data device와 추적 block size를 차례로 지정합니다.

era <metadata dev> <origin dev> <block size>
dm-era constructor
인자의미
`metadata dev`Persistent metadata를 보관하는 빠른 장치
`origin dev`변경될 수 있는 data block을 보관하는 장치
`block size`Origin data device의 block size이자 target 추적 granularity

Persistent metadata 위치와 changed-block 추적 단위를 정의합니다.

 ================ ======================================================
 metadata dev     fast device holding the persistent metadata
 origin dev	  device holding data blocks that may change
 block size       block size of origin data device, granularity that is
		  tracked by the target
 ================ ======================================================

Checkpoint와 metadata snapshot message

30-51

모든 dm message는 인자를 받지 않습니다.

dm-era message
Message동작주의
`checkpoint`가능하면 새 era로 이동반드시 증가한다고 가정하지 말고 status의 current era 확인
`take_metadata_snap`Userspace process가 읽을 수 있도록 metadata clone 생성Held metadata root가 status에 표시됨
`drop_metadata_snap`Metadata snapshot 해제Held root 제거

Era 전환과 userspace metadata 읽기용 snapshot을 제어합니다.

Checkpoint 확인
`checkpoint` 전송Target이 전환 가능성 평가Status line 조회`current era` 기록

Message 성공과 era 증가 여부를 분리해 status로 최종 확인합니다.

Metadata 사용량, current era와 held root

52-68

Status는 metadata block size와 사용량, current era, userspace read를 위해 hold한 metadata root 위치를 반환합니다.

<metadata block size> <#used metadata blocks>/<#total metadata blocks>
<current era> <held metadata root | '-'>
dm-era status 필드
필드의미
`metadata block size`각 metadata block의 고정 sector 크기
`#used metadata blocks`사용 중인 metadata block 수
`#total metadata blocks`전체 metadata block 수
`current era`현재 단조 증가 era counter
`held metadata root`Userspace read access를 위해 hold한 metadata root의 block 위치. 없으면 `-`

Metadata 공간과 snapshot-access 상태를 보여 줍니다.

========================= ==============================================
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
current era		  The current era
held metadata root	  The location, in blocks, of the metadata root
			  that has been 'held' for userspace read
			  access. '-' indicates there is no held root
========================= ==============================================

Vendor snapshot 생성과 rollback cache 복구

69-93

Vendor snapshot rollback 뒤 cache를 invalidate하는 시나리오가 target 개발의 주된 use case였습니다.

Vendor snapshot 생성
Era target에 `checkpoint`Status에서 current era 확인·기록Vendor snapshot 생성Snapshot ↔ era 영구 연결

Snapshot과 당시 era 번호를 영구적으로 연결합니다.

Vendor snapshot rollback
Cache를 passthrough mode로 전환Vendor storage rollback`take_metadata_snap`Block별 era 검사Snapshot 이후 write된 block 식별Caching software에서 해당 block invalidatewriteback/writethrough mode 복귀

Snapshot 이후 write된 block만 골라 cache coherency를 복구합니다.

Passthrough mode는 dm-cache 문서를 참고합니다. Rollback 중에는 stale cache data를 사용하지 않고, era metadata snapshot으로 필요한 invalidation 범위를 확정합니다.

두 bitset의 memory 비용과 crash ordering

94-108

Target은 현재 era write를 기록하는 bitset과 새 era로 전환할 때 즉시 사용할 spare bitset을 유지합니다. 그 밖에는 metadata update를 위한 몇 개의 4 KiB buffer를 사용합니다.

   (4 * nr_blocks) bytes + buffers
Memory 사용량
구성비용
Current-era bitsetWrite된 block 추적
Spare bitset다음 era 전환 준비
합계 식`(4 * nr_blocks) bytes + buffers`
Metadata buffers몇 개의 4 KiB block

Block 수에 비례하는 두 bitset과 소수 metadata buffer로 구성됩니다.

이전에 write되지 않은 block에 실제 data write를 수행하기 전에 on-disk metadata를 먼저 갱신합니다. 따라서 power failure 같은 hard crash가 발생해도 `dm-era` 추적 정보가 write보다 뒤처지지 않습니다.

Crash-safe write ordering
Previously unwritten block writeOn-disk era metadata updateData block writePower failure 발생 가능변경 추적 보존

Changed-block metadata를 data보다 먼저 durable하게 만들어 누락을 방지합니다.

thin-provisioning-tools의 userspace 도구

109-116

Userspace 도구는 이름과 달리 범위가 넓어진 `thin-provisioning-tools` project에 있습니다.

    https://github.com/jthornber/thin-provisioning-tools
Userspace project
ProjectURL
`thin-provisioning-tools``https://github.com/jthornber/thin-provisioning-tools`

Metadata를 읽고 era 정보를 활용하는 도구의 upstream 위치입니다.