brintos

brintos / linux-shallow public Read only

0
0
Text · 14.5 KiB · a14e6d3 Raw
413 lines · plain
1.. SPDX-License-Identifier: GPL-2.0-only2 3dm-vdo4======5 6The dm-vdo (virtual data optimizer) device mapper target provides7block-level deduplication, compression, and thin provisioning. As a device8mapper target, it can add these features to the storage stack, compatible9with any file system. The vdo target does not protect against data10corruption, relying instead on integrity protection of the storage below11it. It is strongly recommended that lvm be used to manage vdo volumes. See12lvmvdo(7).13 14Userspace component15===================16 17Formatting a vdo volume requires the use of the 'vdoformat' tool, available18at:19 20https://github.com/dm-vdo/vdo/21 22In most cases, a vdo target will recover from a crash automatically the23next time it is started. In cases where it encountered an unrecoverable24error (either during normal operation or crash recovery) the target will25enter or come up in read-only mode. Because read-only mode is indicative of26data-loss, a positive action must be taken to bring vdo out of read-only27mode. The 'vdoforcerebuild' tool, available from the same repo, is used to28prepare a read-only vdo to exit read-only mode. After running this tool,29the vdo target will rebuild its metadata the next time it is30started. Although some data may be lost, the rebuilt vdo's metadata will be31internally consistent and the target will be writable again.32 33The repo also contains additional userspace tools which can be used to34inspect a vdo target's on-disk metadata. Fortunately, these tools are35rarely needed except by dm-vdo developers.36 37Metadata requirements38=====================39 40Each vdo volume reserves 3GB of space for metadata, or more depending on41its configuration. It is helpful to check that the space saved by42deduplication and compression is not cancelled out by the metadata43requirements. An estimation of the space saved for a specific dataset can44be computed with the vdo estimator tool, which is available at:45 46https://github.com/dm-vdo/vdoestimator/47 48Target interface49================50 51Table line52----------53 54::55 56	<offset> <logical device size> vdo V4 <storage device>57	<storage device size> <minimum I/O size> <block map cache size>58	<block map era length> [optional arguments]59 60 61Required parameters:62 63	offset:64		The offset, in sectors, at which the vdo volume's logical65		space begins.66 67	logical device size:68		The size of the device which the vdo volume will service,69		in sectors. Must match the current logical size of the vdo70		volume.71 72	storage device:73		The device holding the vdo volume's data and metadata.74 75	storage device size:76		The size of the device holding the vdo volume, as a number77		of 4096-byte blocks. Must match the current size of the vdo78		volume.79 80	minimum I/O size:81		The minimum I/O size for this vdo volume to accept, in82		bytes. Valid values are 512 or 4096. The recommended value83		is 4096.84 85	block map cache size:86		The size of the block map cache, as a number of 4096-byte87		blocks. The minimum and recommended value is 32768 blocks.88		If the logical thread count is non-zero, the cache size89		must be at least 4096 blocks per logical thread.90 91	block map era length:92		The speed with which the block map cache writes out93		modified block map pages. A smaller era length is likely to94		reduce the amount of time spent rebuilding, at the cost of95		increased block map writes during normal operation. The96		maximum and recommended value is 16380; the minimum value97		is 1.98 99Optional parameters:100--------------------101Some or all of these parameters may be specified as <key> <value> pairs.102 103Thread related parameters:104 105Different categories of work are assigned to separate thread groups, and106the number of threads in each group can be configured separately.107 108If <hash>, <logical>, and <physical> are all set to 0, the work handled by109all three thread types will be handled by a single thread. If any of these110values are non-zero, all of them must be non-zero.111 112	ack:113		The number of threads used to complete bios. Since114		completing a bio calls an arbitrary completion function115		outside the vdo volume, threads of this type allow the vdo116		volume to continue processing requests even when bio117		completion is slow. The default is 1.118 119	bio:120		The number of threads used to issue bios to the underlying121		storage. Threads of this type allow the vdo volume to122		continue processing requests even when bio submission is123		slow. The default is 4.124 125	bioRotationInterval:126		The number of bios to enqueue on each bio thread before127		switching to the next thread. The value must be greater128		than 0 and not more than 1024; the default is 64.129 130	cpu:131		The number of threads used to do CPU-intensive work, such132		as hashing and compression. The default is 1.133 134	hash:135		The number of threads used to manage data comparisons for136		deduplication based on the hash value of data blocks. The137		default is 0.138 139	logical:140		The number of threads used to manage caching and locking141		based on the logical address of incoming bios. The default142		is 0; the maximum is 60.143 144	physical:145		The number of threads used to manage administration of the146		underlying storage device. At format time, a slab size for147		the vdo is chosen; the vdo storage device must be large148		enough to have at least 1 slab per physical thread. The149		default is 0; the maximum is 16.150 151Miscellaneous parameters:152 153	maxDiscard:154		The maximum size of discard bio accepted, in 4096-byte155		blocks. I/O requests to a vdo volume are normally split156		into 4096-byte blocks, and processed up to 2048 at a time.157		However, discard requests to a vdo volume can be158		automatically split to a larger size, up to <maxDiscard>159		4096-byte blocks in a single bio, and are limited to 1500160		at a time. Increasing this value may provide better overall161		performance, at the cost of increased latency for the162		individual discard requests. The default and minimum is 1;163		the maximum is UINT_MAX / 4096.164 165	deduplication:166		Whether deduplication is enabled. The default is 'on'; the167		acceptable values are 'on' and 'off'.168 169	compression:170		Whether compression is enabled. The default is 'off'; the171		acceptable values are 'on' and 'off'.172 173Device modification174-------------------175 176A modified table may be loaded into a running, non-suspended vdo volume.177The modifications will take effect when the device is next resumed. The178modifiable parameters are <logical device size>, <physical device size>,179<maxDiscard>, <compression>, and <deduplication>.180 181If the logical device size or physical device size are changed, upon182successful resume vdo will store the new values and require them on future183startups. These two parameters may not be decreased. The logical device184size may not exceed 4 PB. The physical device size must increase by at185least 32832 4096-byte blocks if at all, and must not exceed the size of the186underlying storage device. Additionally, when formatting the vdo device, a187slab size is chosen: the physical device size may never increase above the188size which provides 8192 slabs, and each increase must be large enough to189add at least one new slab.190 191Examples:192 193Start a previously-formatted vdo volume with 1 GB logical space and 1 GB194physical space, storing to /dev/dm-1 which has more than 1 GB of space.195 196::197 198	dmsetup create vdo0 --table \199	"0 2097152 vdo V4 /dev/dm-1 262144 4096 32768 16380"200 201Grow the logical size to 4 GB.202 203::204 205	dmsetup reload vdo0 --table \206	"0 8388608 vdo V4 /dev/dm-1 262144 4096 32768 16380"207	dmsetup resume vdo0208 209Grow the physical size to 2 GB.210 211::212 213	dmsetup reload vdo0 --table \214	"0 8388608 vdo V4 /dev/dm-1 524288 4096 32768 16380"215	dmsetup resume vdo0216 217Grow the physical size by 1 GB more and increase max discard sectors.218 219::220 221	dmsetup reload vdo0 --table \222	"0 10485760 vdo V4 /dev/dm-1 786432 4096 32768 16380 maxDiscard 8"223	dmsetup resume vdo0224 225Stop the vdo volume.226 227::228 229	dmsetup remove vdo0230 231Start the vdo volume again. Note that the logical and physical device sizes232must still match, but other parameters can change.233 234::235 236	dmsetup create vdo1 --table \237	"0 10485760 vdo V4 /dev/dm-1 786432 512 65550 5000 hash 1 logical 3 physical 2"238 239Messages240--------241All vdo devices accept messages in the form:242 243::244 245        dmsetup message <target-name> 0 <message-name> <message-parameters>246 247The messages are:248 249        stats:250		Outputs the current view of the vdo statistics. Mostly used251		by the vdostats userspace program to interpret the output252		buffer.253 254	config:255		Outputs useful vdo configuration information. Mostly used256		by users who want to recreate a similar VDO volume and257		want to know the creation configuration used.258 259	dump:260		Dumps many internal structures to the system log. This is261		not always safe to run, so it should only be used to debug262		a hung vdo. Optional parameters to specify structures to263		dump are:264 265			viopool: The pool of I/O requests incoming bios266			pools: A synonym of 'viopool'267			vdo: Most of the structures managing on-disk data268			queues: Basic information about each vdo thread269			threads: A synonym of 'queues'270			default: Equivalent to 'queues vdo'271			all: All of the above.272 273        dump-on-shutdown:274		Perform a default dump next time vdo shuts down.275 276 277Status278------279 280::281 282    <device> <operating mode> <in recovery> <index state>283    <compression state> <physical blocks used> <total physical blocks>284 285	device:286		The name of the vdo volume.287 288	operating mode:289		The current operating mode of the vdo volume; values may be290		'normal', 'recovering' (the volume has detected an issue291		with its metadata and is attempting to repair itself), and292		'read-only' (an error has occurred that forces the vdo293		volume to only support read operations and not writes).294 295	in recovery:296		Whether the vdo volume is currently in recovery mode;297		values may be 'recovering' or '-' which indicates not298		recovering.299 300	index state:301		The current state of the deduplication index in the vdo302		volume; values may be 'closed', 'closing', 'error',303		'offline', 'online', 'opening', and 'unknown'.304 305	compression state:306		The current state of compression in the vdo volume; values307		may be 'offline' and 'online'.308 309	used physical blocks:310		The number of physical blocks in use by the vdo volume.311 312	total physical blocks:313		The total number of physical blocks the vdo volume may use;314		the difference between this value and the315		<used physical blocks> is the number of blocks the vdo316		volume has left before being full.317 318Memory Requirements319===================320 321A vdo target requires a fixed 38 MB of RAM along with the following amounts322that scale with the target:323 324- 1.15 MB of RAM for each 1 MB of configured block map cache size. The325  block map cache requires a minimum of 150 MB.326- 1.6 MB of RAM for each 1 TB of logical space.327- 268 MB of RAM for each 1 TB of physical storage managed by the volume.328 329The deduplication index requires additional memory which scales with the330size of the deduplication window. For dense indexes, the index requires 1331GB of RAM per 1 TB of window. For sparse indexes, the index requires 1 GB332of RAM per 10 TB of window. The index configuration is set when the target333is formatted and may not be modified.334 335Module Parameters336=================337 338The vdo driver has a numeric parameter 'log_level' which controls the339verbosity of logging from the driver. The default setting is 6340(LOGLEVEL_INFO and more severe messages).341 342Run-time Usage343==============344 345When using dm-vdo, it is important to be aware of the ways in which its346behavior differs from other storage targets.347 348- There is no guarantee that over-writes of existing blocks will succeed.349  Because the underlying storage may be multiply referenced, over-writing350  an existing block generally requires a vdo to have a free block351  available.352 353- When blocks are no longer in use, sending a discard request for those354  blocks lets the vdo release references for those blocks. If the vdo is355  thinly provisioned, discarding unused blocks is essential to prevent the356  target from running out of space. However, due to the sharing of357  duplicate blocks, no discard request for any given logical block is358  guaranteed to reclaim space.359 360- Assuming the underlying storage properly implements flush requests, vdo361  is resilient against crashes, however, unflushed writes may or may not362  persist after a crash.363 364- Each write to a vdo target entails a significant amount of processing.365  However, much of the work is paralellizable. Therefore, vdo targets366  achieve better throughput at higher I/O depths, and can support up 2048367  requests in parallel.368 369Tuning370======371 372The vdo device has many options, and it can be difficult to make optimal373choices without perfect knowledge of the workload. Additionally, most374configuration options must be set when a vdo target is started, and cannot375be changed without shutting it down completely; the configuration cannot be376changed while the target is active. Ideally, tuning with simulated377workloads should be performed before deploying vdo in production378environments.379 380The most important value to adjust is the block map cache size. In order to381service a request for any logical address, a vdo must load the portion of382the block map which holds the relevant mapping. These mappings are cached.383Performance will suffer when the working set does not fit in the cache. By384default, a vdo allocates 128 MB of metadata cache in RAM to support385efficient access to 100 GB of logical space at a time. It should be scaled386up proportionally for larger working sets.387 388The logical and physical thread counts should also be adjusted. A logical389thread controls a disjoint section of the block map, so additional logical390threads increase parallelism and can increase throughput. Physical threads391control a disjoint section of the data blocks, so additional physical392threads can also increase throughput. However, excess threads can waste393resources and increase contention.394 395Bio submission threads control the parallelism involved in sending I/O to396the underlying storage; fewer threads mean there is more opportunity to397reorder I/O requests for performance benefit, but also that each I/O398request has to wait longer before being submitted.399 400Bio acknowledgment threads are used for finishing I/O requests. This is401done on dedicated threads since the amount of work required to execute a402bio's callback can not be controlled by the vdo itself. Usually one thread403is sufficient but additional threads may be beneficial, particularly when404bios have CPU-heavy callbacks.405 406CPU threads are used for hashing and for compression; in workloads with407compression enabled, more threads may result in higher throughput.408 409Hash threads are used to sort active requests by hash and determine whether410they should deduplicate; the most CPU intensive actions done by these411threads are comparison of 4096-byte data blocks. In most cases, a single412hash thread is sufficient.413