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.
101