Lines Matching +full:cache +full:- +full:block
2 Cache title
8 dm-cache is a device mapper target written by Joe Thornber, Heinz
11 It aims to improve performance of a block device (eg, a spindle) by
15 This device-mapper solution allows us to insert this caching at
17 a thin-provisioning pool. Caching solutions that are integrated more
20 The target reuses the metadata library used in the thin-provisioning
23 The decision as to what data to migrate and when is left to a plug-in
32 Movement of the primary copy of a logical block from one
39 The origin device always contains a copy of the logical block, which
40 may be out of date or kept in sync with the copy on the cache device
46 Sub-devices
47 -----------
52 1. An origin device - the big, slow one.
54 2. A cache device - the small, fast one.
56 3. A small metadata device - records which blocks are in the cache,
58 This information could be put on the cache device, but having it
61 be used by a single cache device.
63 Fixed block size
64 ----------------
66 The origin is divided up into blocks of a fixed size. This block size
67 is configurable when you first create the cache. Typically we've been
68 using block sizes of 256KB - 1024KB. The block size must be between 64
71 Having a fixed block size simplifies the target a lot. But it is
72 something of a compromise. For instance, a small part of a block may be
73 getting hit a lot, yet the whole block will be promoted to the cache.
74 So large block sizes are bad because they waste cache space. And small
75 block sizes are bad because they increase the amount of metadata (both
78 Cache operating modes
79 ---------------------
81 The cache has three operating modes: writeback, writethrough and
84 If writeback, the default, is selected then a write to a block that is
85 cached will go only to the cache and the block will be marked dirty in
88 If writethrough is selected then a write to a cached block will not
89 complete until it has hit both the origin and cache devices. Clean
92 If passthrough is selected, useful when the cache contents are not known
94 the origin device (all reads miss the cache) and all writes are
95 forwarded to the origin device; additionally, write hits cause cache
96 block invalidates. To enable passthrough mode the cache must be clean.
97 Passthrough mode allows a cache device to be activated without having to
99 the cache will gradually cool as writes take place. If the coherency of
100 the cache can later be verified, or established through use of the
101 "invalidate_cblocks" message, the cache device can be transitioned to
102 writethrough or writeback mode while still warm. Otherwise, the cache
107 dirty blocks in a cache. Useful for decommissioning a cache or when
108 shrinking a cache. Shrinking the cache's fast device requires all cache
109 blocks, in the area of the cache being removed, to be clean. If the
110 area being removed from the cache still contains dirty blocks the resize
112 cache's fast device until the cache is clean. This is of particular
114 modes already maintain a clean cache. Future support to partially clean
115 the cache, above a specified threshold, will allow for keeping the cache
119 --------------------
121 Migrating data between the origin and cache device uses bandwidth.
131 Updating on-disk metadata
132 -------------------------
134 On-disk metadata is committed every time a FLUSH or FUA bio is written.
136 means the cache behaves like a physical disk that has a volatile write
137 cache. If power is lost you may lose some recent writes. The metadata
140 The 'dirty' state for a cache block changes far too frequently for us
143 system crashes all cache blocks will be assumed dirty when restarted.
145 Per-block policy hints
146 ----------------------
148 Policy plug-ins can store a chunk of data per cache block. It's up to
156 ----------------
159 need a generic way of getting and setting these. Device-mapper
160 messages are used. Refer to cache-policies.txt.
163 -------------------------
165 We can avoid copying data during migration if we know the block has
167 whole block device. We store a bitset tracking the discard state of
168 blocks. However, we allow this bitset to have a different block size
169 from the cache blocks. This is because we need to track the discard
171 which is just for the smaller cache device).
177 -----------
181 cache <metadata dev> <cache dev> <origin dev> <block size>
187 cache dev fast device holding cached data blocks
189 block size cache unit size in sectors
199 See cache-policies.txt for details.
206 writethrough write through caching that prohibits cache block
207 content from being different from origin block content.
209 back cache block contents later for performance reasons,
212 passthrough a degraded mode useful for various cache coherency
216 block, then the cache block is invalidated.
217 To enable passthrough mode the cache must be clean.
221 shutting down the cache.
223 no_discard_passdown disable passing down discards from the cache
234 ------
238 <metadata block size> <#used metadata blocks>/<#total metadata blocks>
239 <cache block size> <#used cache blocks>/<#total cache blocks>
243 <cache metadata mode>
247 metadata block size Fixed block size for each metadata block in
251 cache block size Configurable block size for the cache device
253 #used cache blocks Number of blocks resident in the cache
254 #total cache blocks Total number of cache blocks
256 to the cache
260 to the cache
263 #demotions Number of times a block has been removed
264 from the cache
265 #promotions Number of times a block has been moved to
266 the cache
267 #dirty Number of blocks in the cache that differ
277 cache metadata mode ro if read-only, rw if read-write
279 In serious cases where even a read-only mode is
283 needs_check 'needs_check' if set, '-' if not set
288 cache can be made fully operational again.
289 '-' indicates needs_check is not set.
293 --------
296 need a generic way of getting and setting these. Device-mapper
308 Invalidation is removing an entry from the cache without writing it
309 back. Cache blocks can be invalidated via the invalidate_cblocks
311 range's end value is "one past the end", meaning 5-10 expresses a range
315 invalidation of larger caches. The cache must be in passthrough mode
318 invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*
322 dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789
329 https://github.com/jthornber/device-mapper-test-suite
333 dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
335 dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \