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
815. the number of read requests
826. the number of read requests that hit the cache
837. the number of write requests
848. the number of write requests that hit uncommitted block
859. the number of write requests that hit committed block
8610. the number of write requests that bypass the cache
8711. the number of write requests that are allocated in the cache
8812. the number of write requests that are blocked on the freelist
8913. the number of flush requests
9014. the number of discard requests
91
92Messages:
93 flush
94 Flush the cache device. The message returns successfully
95 if the cache device was flushed without an error
96 flush_on_suspend
97 Flush the cache device on next suspend. Use this message
98 when you are going to remove the cache device. The proper
99 sequence for removing the cache device is:
100
101 1. send the "flush_on_suspend" message
102 2. load an inactive table with a linear target that maps
103 to the underlying device
104 3. suspend the device
105 4. ask for status and verify that there are no errors
106 5. resume the device, so that it will use the linear
107 target
108 6. the cache device is now inactive and it can be deleted
109 cleaner
110 See above "cleaner" constructor documentation.
111 clear_stats
112 Clear the statistics that are reported on the status line