[mirror_ubuntu-jammy-kernel.git] / Documentation / device-mapper / writecache.txt

The writecache target caches writes on persistent memory or on SSD. It
doesn't cache reads because reads are supposed to be cached in page cache
in normal RAM.

When the device is constructed, the first sector should be zeroed or the
first sector should contain valid superblock from previous invocation.

Constructor parameters:
1. type of the cache device - "p" or "s"
	p - persistent memory
	s - SSD
2. the underlying device that will be cached
3. the cache device
4. block size (4096 is recommended; the maximum block size is the page
   size)
5. the number of optional parameters (the parameters with an argument
   count as two)
	start_sector n		(default: 0)
		offset from the start of cache device in 512-byte sectors
	high_watermark n	(default: 50)
		start writeback when the number of used blocks reach this
		watermark
	low_watermark x		(default: 45)
		stop writeback when the number of used blocks drops below
		this watermark
	writeback_jobs n	(default: unlimited)
		limit the number of blocks that are in flight during
		writeback. Setting this value reduces writeback
		throughput, but it may improve latency of read requests
	autocommit_blocks n	(default: 64 for pmem, 65536 for ssd)
		when the application writes this amount of blocks without
		issuing the FLUSH request, the blocks are automatically
		commited
	autocommit_time ms	(default: 1000)
		autocommit time in milliseconds. The data is automatically
		commited if this time passes and no FLUSH request is
		received
	fua			(by default on)
		applicable only to persistent memory - use the FUA flag
		when writing data from persistent memory back to the
		underlying device
	nofua
		applicable only to persistent memory - don't use the FUA
		flag when writing back data and send the FLUSH request
		afterwards
		- some underlying devices perform better with fua, some
		  with nofua. The user should test it

Status:
1. error indicator - 0 if there was no error, otherwise error number
2. the number of blocks
3. the number of free blocks
4. the number of blocks under writeback

Messages:
	flush
		flush the cache device. The message returns successfully
		if the cache device was flushed without an error
	flush_on_suspend
		flush the cache device on next suspend. Use this message
		when you are going to remove the cache device. The proper
		sequence for removing the cache device is:
		1. send the "flush_on_suspend" message
		2. load an inactive table with a linear target that maps
		   to the underlying device
		3. suspend the device
		4. ask for status and verify that there are no errors
		5. resume the device, so that it will use the linear
		   target
		6. the cache device is now inactive and it can be deleted
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)
d284f824 MP	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