Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tjh.dev
kernel
os
linux
1=================
2Writecache target
3=================
4
5The writecache target caches writes on persistent memory or on SSD. It
6doesn't cache reads because reads are supposed to be cached in page cache
7in normal RAM.
8
9When the device is constructed, the first sector should be zeroed or the
10first sector should contain valid superblock from previous invocation.
11
12Constructor parameters:
13
141. type of the cache device - "p" or "s"
15 - p - persistent memory
16 - s - SSD
172. the underlying device that will be cached
183. the cache device
194. block size (4096 is recommended; the maximum block size is the page
20 size)
215. the number of optional parameters (the parameters with an argument
22 count as two)
23 start_sector n (default: 0)
24 offset from the start of cache device in 512-byte sectors
25 high_watermark n (default: 50)
26 start writeback when the number of used blocks reach this
27 watermark
28 low_watermark x (default: 45)
29 stop writeback when the number of used blocks drops below
30 this watermark
31 writeback_jobs n (default: unlimited)
32 limit the number of blocks that are in flight during
33 writeback. Setting this value reduces writeback
34 throughput, but it may improve latency of read requests
35 autocommit_blocks n (default: 64 for pmem, 65536 for ssd)
36 when the application writes this amount of blocks without
37 issuing the FLUSH request, the blocks are automatically
38 committed
39 autocommit_time ms (default: 1000)
40 autocommit time in milliseconds. The data is automatically
41 committed if this time passes and no FLUSH request is
42 received
43 fua (by default on)
44 applicable only to persistent memory - use the FUA flag
45 when writing data from persistent memory back to the
46 underlying device
47 nofua
48 applicable only to persistent memory - don't use the FUA
49 flag when writing back data and send the FLUSH request
50 afterwards
51
52 - some underlying devices perform better with fua, some
53 with nofua. The user should test it
54 cleaner
55 when this option is activated (either in the constructor
56 arguments or by a message), the cache will not promote
57 new writes (however, writes to already cached blocks are
58 promoted, to avoid data corruption due to misordered
59 writes) and it will gradually writeback any cached
60 data. The userspace can then monitor the cleaning
61 process with "dmsetup status". When the number of cached
62 blocks drops to zero, userspace can unload the
63 dm-writecache target and replace it with dm-linear or
64 other targets.
65 max_age n
66 specifies the maximum age of a block in milliseconds. If
67 a block is stored in the cache for too long, it will be
68 written to the underlying device and cleaned up.
69 metadata_only
70 only metadata is promoted to the cache. This option
71 improves performance for heavier REQ_META workloads.
72 pause_writeback n (default: 3000)
73 pause writeback if there was some write I/O redirected to
74 the origin volume in the last n milliseconds
75
76Status:
771. error indicator - 0 if there was no error, otherwise error number
782. the number of blocks
793. the number of free blocks
804. the number of blocks under writeback
81
82Messages:
83 flush
84 flush the cache device. The message returns successfully
85 if the cache device was flushed without an error
86 flush_on_suspend
87 flush the cache device on next suspend. Use this message
88 when you are going to remove the cache device. The proper
89 sequence for removing the cache device is:
90
91 1. send the "flush_on_suspend" message
92 2. load an inactive table with a linear target that maps
93 to the underlying device
94 3. suspend the device
95 4. ask for status and verify that there are no errors
96 5. resume the device, so that it will use the linear
97 target
98 6. the cache device is now inactive and it can be deleted
99 cleaner
100 See above "cleaner" constructor documentation.