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
16	- p - persistent memory
17	- s - SSD
182. the underlying device that will be cached
193. the cache device
204. block size (4096 is recommended; the maximum block size is the page
21   size)
225. the number of optional parameters (the parameters with an argument
23   count as two)
24
25	start_sector n		(default: 0)
26		offset from the start of cache device in 512-byte sectors
27	high_watermark n	(default: 50)
28		start writeback when the number of used blocks reach this
29		watermark
30	low_watermark x		(default: 45)
31		stop writeback when the number of used blocks drops below
32		this watermark
33	writeback_jobs n	(default: unlimited)
34		limit the number of blocks that are in flight during
35		writeback. Setting this value reduces writeback
36		throughput, but it may improve latency of read requests
37	autocommit_blocks n	(default: 64 for pmem, 65536 for ssd)
38		when the application writes this amount of blocks without
39		issuing the FLUSH request, the blocks are automatically
40		committed
41	autocommit_time ms	(default: 1000)
42		autocommit time in milliseconds. The data is automatically
43		committed if this time passes and no FLUSH request is
44		received
45	fua			(by default on)
46		applicable only to persistent memory - use the FUA flag
47		when writing data from persistent memory back to the
48		underlying device
49	nofua
50		applicable only to persistent memory - don't use the FUA
51		flag when writing back data and send the FLUSH request
52		afterwards
53
54		- some underlying devices perform better with fua, some
55		  with nofua. The user should test it
56	cleaner
57		when this option is activated (either in the constructor
58		arguments or by a message), the cache will not promote
59		new writes (however, writes to already cached blocks are
60		promoted, to avoid data corruption due to misordered
61		writes) and it will gradually writeback any cached
62		data. The userspace can then monitor the cleaning
63		process with "dmsetup status". When the number of cached
64		blocks drops to zero, userspace can unload the
65		dm-writecache target and replace it with dm-linear or
66		other targets.
67	max_age n
68		specifies the maximum age of a block in milliseconds. If
69		a block is stored in the cache for too long, it will be
70		written to the underlying device and cleaned up.
71
72Status:
731. error indicator - 0 if there was no error, otherwise error number
742. the number of blocks
753. the number of free blocks
764. the number of blocks under writeback
77
78Messages:
79	flush
80		flush the cache device. The message returns successfully
81		if the cache device was flushed without an error
82	flush_on_suspend
83		flush the cache device on next suspend. Use this message
84		when you are going to remove the cache device. The proper
85		sequence for removing the cache device is:
86
87		1. send the "flush_on_suspend" message
88		2. load an inactive table with a linear target that maps
89		   to the underlying device
90		3. suspend the device
91		4. ask for status and verify that there are no errors
92		5. resume the device, so that it will use the linear
93		   target
94		6. the cache device is now inactive and it can be deleted
95	cleaner
96		See above "cleaner" constructor documentation.
97