Commit | Line | Data |
---|---|---|
48debafe MP |
1 | The writecache target caches writes on persistent memory or on SSD. It |
2 | doesn't cache reads because reads are supposed to be cached in page cache | |
3 | in normal RAM. | |
4 | ||
5 | When the device is constructed, the first sector should be zeroed or the | |
6 | first sector should contain valid superblock from previous invocation. | |
7 | ||
8 | Constructor parameters: | |
9 | 1. type of the cache device - "p" or "s" | |
10 | p - persistent memory | |
11 | s - SSD | |
12 | 2. the underlying device that will be cached | |
13 | 3. the cache device | |
14 | 4. block size (4096 is recommended; the maximum block size is the page | |
15 | size) | |
16 | 5. the number of optional parameters (the parameters with an argument | |
17 | count as two) | |
d284f824 MP |
18 | start_sector n (default: 0) |
19 | offset from the start of cache device in 512-byte sectors | |
48debafe MP |
20 | high_watermark n (default: 50) |
21 | start writeback when the number of used blocks reach this | |
22 | watermark | |
23 | low_watermark x (default: 45) | |
24 | stop writeback when the number of used blocks drops below | |
25 | this watermark | |
26 | writeback_jobs n (default: unlimited) | |
27 | limit the number of blocks that are in flight during | |
28 | writeback. Setting this value reduces writeback | |
29 | throughput, but it may improve latency of read requests | |
30 | autocommit_blocks n (default: 64 for pmem, 65536 for ssd) | |
31 | when the application writes this amount of blocks without | |
32 | issuing the FLUSH request, the blocks are automatically | |
33 | commited | |
34 | autocommit_time ms (default: 1000) | |
35 | autocommit time in milliseconds. The data is automatically | |
36 | commited if this time passes and no FLUSH request is | |
37 | received | |
38 | fua (by default on) | |
39 | applicable only to persistent memory - use the FUA flag | |
40 | when writing data from persistent memory back to the | |
41 | underlying device | |
42 | nofua | |
43 | applicable only to persistent memory - don't use the FUA | |
44 | flag when writing back data and send the FLUSH request | |
45 | afterwards | |
46 | - some underlying devices perform better with fua, some | |
47 | with nofua. The user should test it | |
48 | ||
49 | Status: | |
50 | 1. error indicator - 0 if there was no error, otherwise error number | |
51 | 2. the number of blocks | |
52 | 3. the number of free blocks | |
53 | 4. the number of blocks under writeback | |
54 | ||
55 | Messages: | |
56 | flush | |
57 | flush the cache device. The message returns successfully | |
58 | if the cache device was flushed without an error | |
59 | flush_on_suspend | |
60 | flush the cache device on next suspend. Use this message | |
61 | when you are going to remove the cache device. The proper | |
62 | sequence for removing the cache device is: | |
63 | 1. send the "flush_on_suspend" message | |
64 | 2. load an inactive table with a linear target that maps | |
65 | to the underlying device | |
66 | 3. suspend the device | |
67 | 4. ask for status and verify that there are no errors | |
68 | 5. resume the device, so that it will use the linear | |
69 | target | |
70 | 6. the cache device is now inactive and it can be deleted |