diff options
Diffstat (limited to 'Documentation/device-mapper/cache-policies.txt')
-rw-r--r-- | Documentation/device-mapper/cache-policies.txt | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt new file mode 100644 index 000000000000..731879f97b80 --- /dev/null +++ b/Documentation/device-mapper/cache-policies.txt | |||
@@ -0,0 +1,72 @@ | |||
1 | Guidance for writing policies | ||
2 | ============================= | ||
3 | |||
4 | Try to keep transactionality out of it. The core is careful to | ||
5 | avoid asking about anything that is migrating. This is a pain, but | ||
6 | makes it easier to write the policies. | ||
7 | |||
8 | Mappings are loaded into the policy at construction time. | ||
9 | |||
10 | Every bio that is mapped by the target is referred to the policy. | ||
11 | The policy can return a simple HIT or MISS or issue a migration. | ||
12 | |||
13 | Currently there's no way for the policy to issue background work, | ||
14 | e.g. to start writing back dirty blocks that are going to be evicte | ||
15 | soon. | ||
16 | |||
17 | Because we map bios, rather than requests it's easy for the policy | ||
18 | to get fooled by many small bios. For this reason the core target | ||
19 | issues periodic ticks to the policy. It's suggested that the policy | ||
20 | doesn't update states (eg, hit counts) for a block more than once | ||
21 | for each tick. The core ticks by watching bios complete, and so | ||
22 | trying to see when the io scheduler has let the ios run. | ||
23 | |||
24 | |||
25 | Overview of supplied cache replacement policies | ||
26 | =============================================== | ||
27 | |||
28 | multiqueue | ||
29 | ---------- | ||
30 | |||
31 | This policy is the default. | ||
32 | |||
33 | The multiqueue policy has two sets of 16 queues: one set for entries | ||
34 | waiting for the cache and another one for those in the cache. | ||
35 | Cache entries in the queues are aged based on logical time. Entry into | ||
36 | the cache is based on variable thresholds and queue selection is based | ||
37 | on hit count on entry. The policy aims to take different cache miss | ||
38 | costs into account and to adjust to varying load patterns automatically. | ||
39 | |||
40 | Message and constructor argument pairs are: | ||
41 | 'sequential_threshold <#nr_sequential_ios>' and | ||
42 | 'random_threshold <#nr_random_ios>'. | ||
43 | |||
44 | The sequential threshold indicates the number of contiguous I/Os | ||
45 | required before a stream is treated as sequential. The random threshold | ||
46 | is the number of intervening non-contiguous I/Os that must be seen | ||
47 | before the stream is treated as random again. | ||
48 | |||
49 | The sequential and random thresholds default to 512 and 4 respectively. | ||
50 | |||
51 | Large, sequential ios are probably better left on the origin device | ||
52 | since spindles tend to have good bandwidth. The io_tracker counts | ||
53 | contiguous I/Os to try to spot when the io is in one of these sequential | ||
54 | modes. | ||
55 | |||
56 | Examples | ||
57 | ======== | ||
58 | |||
59 | The syntax for a table is: | ||
60 | cache <metadata dev> <cache dev> <origin dev> <block size> | ||
61 | <#feature_args> [<feature arg>]* | ||
62 | <policy> <#policy_args> [<policy arg>]* | ||
63 | |||
64 | The syntax to send a message using the dmsetup command is: | ||
65 | dmsetup message <mapped device> 0 sequential_threshold 1024 | ||
66 | dmsetup message <mapped device> 0 random_threshold 8 | ||
67 | |||
68 | Using dmsetup: | ||
69 | dmsetup create blah --table "0 268435456 cache /dev/sdb /dev/sdc \ | ||
70 | /dev/sdd 512 0 mq 4 sequential_threshold 1024 random_threshold 8" | ||
71 | creates a 128GB large mapped device named 'blah' with the | ||
72 | sequential threshold set to 1024 and the random_threshold set to 8. | ||