1 ======
2 dm-era
3 ======
4
5 Introduction
6 ============
7
8 dm-era is a target that behaves similar to the
9 addition it keeps track of which blocks were w
10 defined period of time called an 'era'. Each
11 maintains the current era as a monotonically i
12 counter.
13
14 Use cases include tracking changed blocks for
15 partially invalidating the contents of a 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 pers
25 origin dev device holding data blocks t
26 block size block size of origin data de
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 ass
39 incremented. After sending this message, you
40 current era via the status line.
41
42 take_metadata_snap
43 ------------------
44
45 Create a clone of the metadata, to allow a use
46
47 drop_metadata_snap
48 ------------------
49
50 Drop the metadata snapshot.
51
52 Status
53 ======
54
55 <metadata block size> <#used metadata blocks>/
56 <current era> <held metadata root | '-'>
57
58 ========================= ====================
59 metadata block size Fixed block size for
60 sectors
61 #used metadata blocks Number of metadata b
62 #total metadata blocks Total number of meta
63 current era The current era
64 held metadata root The location, in blo
65 that has been 'held'
66 access. '-' indicate
67 ========================= ====================
68
69 Detailed use case
70 =================
71
72 The scenario of invalidating a cache when roll
73 snapshot was the primary use case when develop
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
80 - Take vendor snapshot (the era and snapshot s
81 associated now).
82
83 Rolling back to an vendor snapshot
84 ----------------------------------
85
86 - Cache enters passthrough mode (see: dm-cache
87 - Rollback vendor storage
88 - Take metadata snapshot
89 - Ascertain which blocks have been written sin
90 by checking each block's era
91 - Invalidate those blocks in the caching softw
92 - Cache returns to writeback/writethrough mode
93
94 Memory usage
95 ============
96
97 The target uses a bitset to record writes in t
98 has a spare bitset ready for switching over to
99 that it uses a few 4k blocks for updating meta
100
101 (4 * nr_blocks) bytes + buffers
102
103 Resilience
104 ==========
105
106 Metadata is updated on disk before a write to
107 block is performed. As such dm-era should not
108 crash such as power failure.
109
110 Userland tools
111 ==============
112
113 Userland tools are found in the increasingly p
114 thin-provisioning-tools project:
115
116 https://github.com/jthornber/thin-provisio
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.