Lines Matching +full:block +full:- +full:size
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
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,
63 Fixed block size
64 ----------------
66 The origin is divided up into blocks of a fixed size. This block size
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
79 ---------------------
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
96 block invalidates. To enable passthrough mode the cache must be clean.
119 --------------------
131 Updating on-disk metadata
132 -------------------------
134 On-disk metadata is committed every time a FLUSH or FUA bio is written.
140 The 'dirty' state for a cache block changes far too frequently for us
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
177 -----------
181 cache <metadata dev> <cache dev> <origin dev> <block size>
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,
216 block, then the cache block is invalidated.
234 ------
238 <metadata block size> <#used metadata blocks>/<#total metadata blocks>
239 <cache block size> <#used cache blocks>/<#total cache blocks>
247 metadata block size Fixed block size for each metadata block in
251 cache block size Configurable block size for the cache device
263 #demotions Number of times a block has been removed
265 #promotions Number of times a block has been moved to
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
289 '-' indicates needs_check is not set.
293 --------
296 need a generic way of getting and setting these. Device-mapper
311 range's end value is "one past the end", meaning 5-10 expresses a range
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 \