diff options
| -rw-r--r-- | man/blkdeactivate.8_main | 81 | ||||
| -rw-r--r-- | man/cmirrord.8_main | 30 | ||||
| -rw-r--r-- | man/dmeventd.8_main | 77 | ||||
| -rw-r--r-- | man/dmfilemapd.8_main | 79 | ||||
| -rw-r--r-- | man/dmsetup.8_main | 190 | ||||
| -rw-r--r-- | man/dmstats.8_main | 418 | ||||
| -rw-r--r-- | man/fsadm.8_main | 46 | ||||
| -rw-r--r-- | man/lvm.8_main | 54 | ||||
| -rw-r--r-- | man/lvm.conf.5_main | 83 | ||||
| -rw-r--r-- | man/lvm2-activation-generator.8_main | 53 | ||||
| -rw-r--r-- | man/lvmcache.7_main | 472 | ||||
| -rw-r--r-- | man/lvmdbusd.8_main | 19 | ||||
| -rw-r--r-- | man/lvmdump.8_main | 79 | ||||
| -rw-r--r-- | man/lvmlockctl.8_main | 135 | ||||
| -rw-r--r-- | man/lvmlockd.8_main | 614 | ||||
| -rw-r--r-- | man/lvmpolld.8_main | 56 | ||||
| -rw-r--r-- | man/lvmreport.7_main | 332 | ||||
| -rw-r--r-- | man/lvmsadc.8_main | 18 | ||||
| -rw-r--r-- | man/lvmsar.8_main | 18 | ||||
| -rw-r--r-- | man/lvmsystemid.7_main | 200 | ||||
| -rw-r--r-- | man/lvmthin.7_main | 809 | ||||
| -rw-r--r-- | man/lvmvdo.7_main | 172 |
22 files changed, 1972 insertions, 2063 deletions
diff --git a/man/blkdeactivate.8_main b/man/blkdeactivate.8_main index 06af52e52..a832b1af1 100644 --- a/man/blkdeactivate.8_main +++ b/man/blkdeactivate.8_main @@ -1,19 +1,34 @@ .TH "BLKDEACTIVATE" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" -.SH "NAME" +. +.SH NAME +. blkdeactivate \(em utility to deactivate block devices +. .SH SYNOPSIS +. +.ad l +.nh .B blkdeactivate -.RB [ -d \ \fIdm_options\fP ] +.RB [ -d +.IR dm_options ] .RB [ -e ] .RB [ -h ] -.RB [ -l \ \fIlvm_options\fP ] -.RB [ -m \ \fImpath_options\fP ] -.RB [ -r \ \fImdraid_options\fP ] -.RB [ -o \ \fIvdo_options\fP ] +.RB [ -l +.IR lvm_options ] +.RB [ -m +.IR mpath_options ] +.RB [ -r +.IR mdraid_options ] +.RB [ -o +.IR vdo_options ] .RB [ -u ] .RB [ -v ] .RI [ device ] +.hy +.ad b +. .SH DESCRIPTION +. The blkdeactivate utility deactivates block devices. For mounted block devices, it attempts to unmount it automatically before trying to deactivate. The utility currently supports @@ -22,9 +37,11 @@ software RAID MD devices. LVM volumes are handled directly using the \fBlvm\fP(8) command, the rest of device-mapper based devices are handled using the \fBdmsetup\fP(8) command. MD devices are handled using the \fBmdadm\fP(8) command. +. .SH OPTIONS +. .TP -.BR -d ", " --dmoptions \ \fIdm_options\fP +.BR -d | --dmoptions " " \fIdm_options Comma separated list of device-mapper specific options. Accepted \fBdmsetup\fP(8) options are: .RS @@ -33,17 +50,20 @@ Retry removal several times in case of failure. .IP \fIforce\fP Force device removal. .RE +. .TP -.BR -e ", " --errors +.BR -e | --errors Show errors reported from tools called by \fBblkdeactivate\fP. Without this option, any error messages from these external tools are suppressed and the \fBblkdeactivate\fP itself provides only a summary message to indicate the device was skipped. +. .TP -.BR -h ", " --help +.BR -h | --help Display the help text. +. .TP -.BR -l ", " --lvmoptions \ \fIlvm_options\fP +.BR -l | --lvmoptions " " \fIlvm_options Comma-separated list of LVM specific options: .RS .IP \fIretry\fP @@ -53,8 +73,9 @@ Deactivate the whole LVM Volume Group when processing a Logical Volume. Deactivating the Volume Group as a whole is quicker than deactivating each Logical Volume separately. .RE +. .TP -.BR -m ", " --mpathoptions \ \fImpath_options\fP +.BR -m | --mpathoptions " " \fImpath_options Comma-separated list of device-mapper multipath specific options: .RS .IP \fIdisablequeueing\fP @@ -63,68 +84,74 @@ This avoids a situation where blkdeactivate may end up waiting if all the paths are unavailable for any underlying device-mapper multipath device. .RE +. .TP -.BR -r ", " --mdraidoptions \ \fImdraid_options\fP +.BR -r | --mdraidoptions " " \fImdraid_options Comma-separated list of MD RAID specific options: .RS .IP \fIwait\fP Wait MD device's resync, recovery or reshape action to complete before deactivation. .RE - +. .TP -.BR -o ", " --vdooptions \ \fIvdo_options\fP +.BR -o | --vdooptions " " \fIvdo_options Comma-separated list of VDO specific options: .RS .IP \fIconfigfile=file\fP Use specified VDO configuration file. .RE - +. .TP -.BR -u ", " --umount +.BR -u | --umount Unmount a mounted device before trying to deactivate it. Without this option used, a device that is mounted is not deactivated. +. .TP .BR -v ", " --verbose -Run in verbose mode. Use --vv for even more verbose mode. +Run in verbose mode. Use \fB-vv\fP for even more verbose mode. +. .SH EXAMPLES . Deactivate all supported block devices found in the system, skipping mounted devices. -.BR +.br # .B blkdeactivate -.BR +.br .P Deactivate all supported block devices found in the system, unmounting any mounted devices first, if possible. -.BR +.br # .B blkdeactivate -u -.BR +.br .P -Deactivate the device /dev/vg/lvol0 together with all its holders, unmounting +Deactivate the device /dev/vg/lvol0 together with all its holders, unmounting any mounted devices first, if possible. -.BR +.br # .B blkdeactivate -u /dev/vg/lvol0 -.BR +.br .P Deactivate all supported block devices found in the system. If the deactivation of a device-mapper device fails, retry it. Deactivate the whole Volume Group at once when processing an LVM Logical Volume. -.BR +.br # .B blkdeactivate -u -d retry -l wholevg -.BR +.br .P Deactivate all supported block devices found in the system. If the deactivation of a device-mapper device fails, retry it and force removal. -.BR +.br # .B blkdeactivate -d force,retry . .SH SEE ALSO +. +.nh +.ad l .BR dmsetup (8), .BR lsblk (8), .BR lvm (8), diff --git a/man/cmirrord.8_main b/man/cmirrord.8_main index d49fa52a0..b841ae427 100644 --- a/man/cmirrord.8_main +++ b/man/cmirrord.8_main @@ -1,35 +1,45 @@ .TH CMIRRORD 8 "LVM TOOLS #VERSION#" "Red Hat Inc" \" -*- nroff -*- +. .SH NAME +. cmirrord \(em cluster mirror log daemon - +. .SH SYNOPSIS -\fBcmirrord\fR [\fB-f\fR] [\fB-h\fR] - +. +.B cmirrord +.RB [ -f | --foreground ] +.RB [ -h | --help ] +. .SH DESCRIPTION +. \fBcmirrord\fP is the daemon that tracks mirror log information in a cluster. It is specific to device-mapper based mirrors (and by extension, LVM cluster mirrors). Cluster mirrors are not possible without this daemon running. - +.P This daemon relies on the cluster infrastructure provided by the corosync, which must be set up and running in order for cmirrord to function. - +.P Output is logged via \fBsyslog\fP(3). The \fBSIGUSR1 signal\fP(7) can be issued to \fBcmirrord\fP to gather current status information for debugging purposes. - +.P Once started, \fBcmirrord\fP will run until it is shutdown via \fBSIGINT\fP signal. If there are still active cluster mirrors, however, the signal will be ignored. Active cluster mirrors should be shutdown before stopping the cluster mirror log daemon. - +. .SH OPTIONS -.IP "\fB-f\fR, \fB--foreground\fR" 4 +. +.TP +.BR -f | --foreground Do not fork and log to the terminal. -.IP "\fB-h\fR, \fB--help\fR" 4 +.TP +.BR -h | --help Print usage. - +. .SH SEE ALSO +. .BR lvmlockd (8), .BR lvm (8), .BR syslog (3), diff --git a/man/dmeventd.8_main b/man/dmeventd.8_main index dc4abf627..123073b18 100644 --- a/man/dmeventd.8_main +++ b/man/dmeventd.8_main @@ -23,70 +23,63 @@ dmeventd is the event monitoring daemon for device-mapper devices. Library plugins can register and carry out actions triggered when particular events occur. . -. .SH OPTIONS . -.HP -.BR -d -.br -Repeat from 1 to 3 times ( -.BR -d , +.TP +.B -d +Repeat from 1 to 3 times +.RB ( -d , .BR -dd , -.BR -ddd -) to increase the detail of +.BR -ddd ) +to increase the detail of debug messages sent to syslog. Each extra d adds more debugging information. . -.HP -.BR -f -.br +.TP +.B -f Don't fork, run in the foreground. . -.HP -.BR -h -.br +.TP +.B -h Show help information. . -.HP -.BR -l -.br +.TP +.B -l Log through stdout and stderr instead of syslog. This option works only with option -f, otherwise it is ignored. . -.HP -.BR -? -.br +.TP +.B -? Show help information on stderr. . -.HP -.BR -R -.br +.TP +.B -R Replace a running dmeventd instance. The running dmeventd must be version 2.02.77 or newer. The new dmeventd instance will obtain a list of devices and events to monitor from the currently running daemon. . -.HP -.BR -V -.br +.TP +.B -V Show version of dmeventd. . .SH LVM PLUGINS . -.HP -.BR Mirror +.TP +.B Mirror +Attempts to handle device failure automatically. .br -Attempts to handle device failure automatically. See +See .BR lvm.conf (5). . -.HP -.BR Raid +.TP +.B Raid +Attempts to handle device failure automatically. .br -Attempts to handle device failure automatically. See +See .BR lvm.conf (5). . -.HP -.BR Snapshot -.br +.TP +.B Snapshot Monitors how full a snapshot is becoming and emits a warning to syslog when it exceeds 80% full. The warning is repeated when 85%, 90% and 95% of the snapshot is filled. @@ -95,9 +88,8 @@ See Snapshot which runs out of space gets invalid and when it is mounted, it gets umounted if possible. . -.HP -.BR Thin -.br +.TP +.B Thin Monitors how full a thin pool data and metadata is becoming and emits a warning to syslog when it exceeds 80% full. The warning is repeated when more then 85%, 90% and 95% @@ -123,12 +115,11 @@ Command is executed with environmental variable in this environment will not try to interact with dmeventd. To see the fullness of a thin pool command may check these two environmental variables -\fBDMEVENTD_THIN_POOL_DATA\fP and \fBDMEVENTD_THIN_POOL_METADATA\fP. +\fBDMEVENTD_THIN_POOL_DATA\fP and \fBDMEVENTD_THIN_POOL_\:METADATA\fP. Command can also read status with tools like \fBlvs\fP(8). - -.HP -.BR Vdo -.br +. +.TP +.B Vdo Monitors how full a VDO pool data is becoming and emits a warning to syslog when it exceeds 80% full. The warning is repeated when more then 85%, 90% and 95% diff --git a/man/dmfilemapd.8_main b/man/dmfilemapd.8_main index c93349ad4..864933609 100644 --- a/man/dmfilemapd.8_main +++ b/man/dmfilemapd.8_main @@ -1,23 +1,23 @@ .TH DMFILEMAPD 8 "Dec 17 2016" "Linux" "MAINTENANCE COMMANDS" - +. .de OPT_FD -. RB [ file_descriptor ] +. I file_descriptor .. . .de OPT_GROUP -. RB [ group_id ] +. I group_id .. . .de OPT_PATH -. RB [ abs_path ] +. I abs_path .. . .de OPT_MODE -. RB [ mode ] +. BR inode | path .. . .de OPT_DEBUG -. RB [ foreground [ verbose ]] +. RI [ foreground " [" verbose ]] .. . .SH NAME @@ -29,7 +29,7 @@ dmfilemapd \(em device-mapper filemap monitoring daemon .de CMD_DMFILEMAPD . ad l . nh -. IR dmfilemapd +. BR dmfilemapd . OPT_FD . OPT_GROUP . OPT_PATH @@ -41,15 +41,14 @@ dmfilemapd \(em device-mapper filemap monitoring daemon .CMD_DMFILEMAPD . .PD -.ad b . .SH DESCRIPTION . -The dmfilemapd daemon monitors groups of \fIdmstats\fP regions that +The dmfilemapd daemon monitors groups of \fBdmstats\fP regions that correspond to the extents of a file, adding and removing regions to reflect the changing state of the file on-disk. - -The daemon is normally launched automatically by the \fPdmstats +.P +The daemon is normally launched automatically by the \fBdmstats create\fP command, but can be run manually, either to create a new daemon where one did not previously exist, or to change the options previously used, by killing the existing daemon and starting a new @@ -57,49 +56,48 @@ one. . .SH OPTIONS . -.HP -.BR file_descriptor -.br +.TP +.OPT_FD Specify the file descriptor number for the file to be monitored. The file descriptor must reference a regular file, open for reading, in a local file system that supports the FIEMAP ioctl, and that returns data describing the physical location of extents. - +.sp The process that executes \fBdmfilemapd\fP is responsible for opening the file descriptor that is handed to the daemon. . -.HP -.BR group_id -.br +.TP +.OPT_GROUP The \fBdmstats\fP group identifier of the group that \fBdmfilemapd\fP should update. The group must exist and it should correspond to a set of regions created by a previous filemap operation. . -.HP -.BR abs_path -.br +.TP +.OPT_PATH The absolute path to the file being monitored, at the time that -it was opened. The use of \fBpath\fP by the daemon differs, +it was opened. The use of \fIabs_path\fP by the daemon differs, depending on the filemap following mode in use; see \fBMODES\fP -and the \fBmode\fP option for more information. - -.br -.HP -.BR mode -.br -The filemap monitoring mode the daemon should use: either "inode" -(\fBDM_FILEMAP_FOLLOW_INODE\fP), or "path" +and the \fImode\fP option for more information. +. +.TP +.OPT_MODE +The filemap monitoring mode the daemon. +Use either +.B inode +(\fBDM_FILEMAP_FOLLOW_INODE\fP), or +.B path (\fBDM_FILEMAP_FOLLOW_PATH\fP), to enable follow-inode or follow-path mode respectively. . -.HP -.BR [foreground] +.TP +.RI [ foreground ] .br If set to 1, disable forking and allow the daemon to run in the foreground. . -.HP -.BR [verbose] +.TP +.RI [ verbose ] +.br Control daemon logging. If set to zero, the daemon will close all stdio streams and run silently. If \fBverbose\fP is a number between 1 and 3, stdio will be retained and the daemon will log @@ -112,7 +110,7 @@ The file map monitoring daemon can monitor files in two distinct ways: the mode affects the behaviour of the daemon when a file under monitoring is renamed or unlinked, and the conditions which cause the daemon to terminate. - +.P In both modes, the daemon will always shut down when the group being monitored is deleted. .P @@ -123,7 +121,7 @@ daemon started. The file descriptor referencing the file is kept open at all times, and the daemon will exit when it detects that the file has been unlinked and it is the last holder of a reference to the file. - +.P This mode is useful if the file is expected to be renamed, or moved within the file system, while it is being monitored. .P @@ -134,7 +132,7 @@ line. The file descriptor referencing the file is re-opened on each iteration of the daemon, and the daemon will exit if no file exists at this location (a tolerance is allowed so that a brief delay between removal and replacement is permitted). - +.P This mode is useful if the file is updated by unlinking the original and placing a new file at the same path. . @@ -146,14 +144,14 @@ daemon can only react to new allocations once they have been written, there are inevitably some IO events that cannot be counted when a file is growing, particularly if the file is being extended by a single thread writing beyond EOF (for example, the \fBdd\fP program). - +.P There is a further loss of events in that there is currently no way to atomically resize a \fBdmstats\fP region and preserve its current counter values. This affects files when they grow by extending the final extent, rather than allocating a new extent: any events that had accumulated in the region between any prior operation and the resize are lost. - +.P File mapping is currently most effective in cases where the majority of IO does not trigger extent allocation. Future updates may address these limitations when kernel support is available. @@ -206,8 +204,7 @@ Bryn M. Reeves <bmr@redhat.com> .SH SEE ALSO . .BR dmstats (8) - +.P LVM2 resource page: https://www.sourceware.org/lvm2/ .br Device-mapper resource page: http://sources.redhat.com/dm/ -.br diff --git a/man/dmsetup.8_main b/man/dmsetup.8_main index 528dc877a..aa60a0153 100644 --- a/man/dmsetup.8_main +++ b/man/dmsetup.8_main @@ -24,13 +24,13 @@ dmsetup \(em low level logical volume management . nh . BR create . IR device_name -. RB [ -u | --uuid -. IR uuid ] -. RB [ --addnodeoncreate |\: --addnodeonresume ] . RB [ -n | --notable |\: --table . IR table |\: table_file ] . RB [ --readahead . RB [ + ] \fIsectors |\: auto | none ] +. RB [ -u | --uuid +. IR uuid ] +. RB [ --addnodeoncreate |\: --addnodeonresume ] . hy . ad b .. @@ -86,12 +86,12 @@ dmsetup \(em low level logical volume management . IR count ] . RB [ --interval . IR seconds ] -. RB [ --nameprefixes ] . RB [ --noheadings ] . RB [ -o . IR fields ] . RB [ -O | --sort . IR sort_fields ] +. RB [ --nameprefixes ] . RB [ --separator . IR separator ] . RI [ device_name ] @@ -120,11 +120,11 @@ dmsetup \(em low level logical volume management . BR ls . RB [ --target . IR target_type ] +. RB [ -o +. IR options ] . RB [ --exec . IR command ] . RB [ --tree ] -. RB [ -o -. IR options ] . hy . ad b .. @@ -391,10 +391,10 @@ dmsetup \(em low level logical volume management .CMD_WIPE_TABLE .PD .P -.HP .PD 0 +.TP .B devmap_name \fImajor minor -.HP +.TP .B devmap_name \fImajor:minor .PD .ad b @@ -404,10 +404,10 @@ dmsetup \(em low level logical volume management dmsetup manages logical devices that use the device-mapper driver. Devices are created by loading a table that specifies a target for each sector (512 bytes) in the logical device. - +.P The first argument to dmsetup is a command. The second argument is the logical device name or uuid. - +.P Invoking the dmsetup tool as \fBdevmap_name\fP (which is not normally distributed and is supported only for historical reasons) is equivalent to @@ -417,66 +417,53 @@ only for historical reasons) is equivalent to . .SH OPTIONS . -.HP -.BR --addnodeoncreate -.br +.TP +.B --addnodeoncreate Ensure \fI/dev/mapper\fP node exists after \fBdmsetup create\fP. . -.HP -.BR --addnodeonresume -.br +.TP +.B --addnodeonresume Ensure \fI/dev/mapper\fP node exists after \fBdmsetup resume\fP (default with udev). . -.HP -.BR --checks -.br +.TP +.B --checks Perform additional checks on the operations requested and report potential problems. Useful when debugging scripts. In some cases these checks may slow down operations noticeably. . -.HP +.TP .BR -c | -C | --columns -.br Display output in columns rather than as Field: Value lines. . -.HP -.BR --count -.IR count -.br +.TP +.B --count \fIcount Specify the number of times to repeat a report. Set this to zero continue until interrupted. The default interval is one second. . -.HP +.TP .BR -f | --force -.br Try harder to complete operation. . -.HP +.TP .BR -h | --help -.br Outputs a summary of the commands available, optionally including the list of report fields (synonym with \fBhelp\fP command). . -.HP -.BR --inactive -.br +.TP +.B --inactive When returning any table information from the kernel report on the inactive table instead of the live table. Requires kernel driver version 4.16.0 or above. . -.HP -.BR --interval -.IR seconds -.br +.TP +.B --interval \fIseconds Specify the interval in seconds between successive iterations for repeating reports. If \fB--interval\fP is specified but \fB--count\fP is not, reports will continue to repeat until interrupted. The default interval is one second. . -.HP -.BR --manglename -.BR auto | hex | none -.br +.TP +.BR --manglename " " auto | hex | none Mangle any character not on a whitelist using mangling_mode when processing device-mapper device names and UUIDs. The names and UUIDs are mangled on input and unmangled on output where the mangling mode @@ -493,26 +480,20 @@ Mangling mode could be also set through \fBDM_DEFAULT_NAME_MANGLING_MODE\fP environment variable. . -.HP -.BR -j | --major -.IR major -.br +.TP +.BR -j | --major " " \fImajor Specify the major number. . -.HP -.BR -m | --minor -.IR minor -.br +.TP +.BR -m | --minor " " \fIminor Specify the minor number. . -.HP +.TP .BR -n | --notable -.br When creating a device, don't load any table. . -.HP -.BR --nameprefixes -.br +.TP +.B --nameprefixes Add a "DM_" prefix plus the field name to the output. Useful with \fB--noheadings\fP to produce a list of field=value pairs that can be used to set environment variables @@ -520,45 +501,37 @@ field=value pairs that can be used to set environment variables .BR udev (7) rules). . -.HP -.BR --noheadings +.TP +.B --noheadings Suppress the headings line when using columnar output. . -.HP -.BR --noflush +.TP +.B --noflush Do not flush outstanding I/O when suspending a device, or do not commit thin-pool metadata when obtaining thin-pool status. . -.HP -.BR --nolockfs -.br +.TP +.B --nolockfs Do not attempt to synchronize filesystem eg, when suspending a device. . -.HP -.BR --noopencount -.br +.TP +.B --noopencount Tell the kernel not to supply the open reference count for the device. . -.HP -.BR --noudevrules -.br +.TP +.B --noudevrules Do not allow udev to manage nodes for devices in device-mapper directory. . -.HP -.BR --noudevsync -.br +.TP +.B --noudevsync Do not synchronise with udev when creating, renaming or removing devices. . -.HP -.BR -o | --options -.IR options -.br +.TP +.BR -o | --options " " \fIoptions Specify which fields to display. . -.HP -.BR --readahead -.RB [ + ] \fIsectors | auto | none -.br +.TP +.BR --readahead \ [ + ] \fIsectors | auto | none Specify read ahead size in units of sectors. The default value is \fBauto\fP which allows the kernel to choose a suitable value automatically. The \fB+\fP prefix lets you @@ -566,15 +539,12 @@ specify a minimum value which will not be used if it is smaller than the value chosen by the kernel. The value \fBnone\fP is equivalent to specifying zero. . -.HP +.TP .BR -r | --readonly -.br Set the table being loaded read-only. . -.HP -.BR -S | --select -.IR selection -.br +.TP +.BR -S | --select " " \fIselection Process only items that match \fIselection\fP criteria. If the command is producing report output, adding the "selected" column (\fB-o selected\fP) displays all rows and shows 1 if the row matches the @@ -584,49 +554,38 @@ comparison operators. As a quick help and to see full list of column names that can be used in selection and the set of supported selection operators, check the output of \fBdmsetup\ info\ -c\ -S\ help\fP command. . -.HP -.BR --table -.IR table -.br +.TP +.B --table \fItable Specify a one-line table directly on the command line. See below for more information on the table format. . -.HP -.BR --udevcookie -.IR cookie -.br +.TP +.B --udevcookie \fIcookie Use cookie for udev synchronisation. Note: Same cookie should be used for same type of operations i.e. creation of multiple different devices. It's not adviced to combine different operations on the single device. . -.HP -.BR -u | --uuid -.br +.TP +.BR -u | --uuid " " \fIuuid Specify the \fIuuid\fP. . -.HP +.TP .BR -y | --yes -.br Answer yes to all prompts automatically. . -.HP -.BR -v | --verbose -.RB [ -v | --verbose ] -.br +.TP +.BR -v | --verbose " [" -v | --verbose ] Produce additional output. . -.HP -.BR --verifyudev -.br +.TP +.B --verifyudev If udev synchronisation is enabled, verify that udev operations get performed correctly and try to fix up the device nodes afterwards if not. . -.HP -.BR --version -.br +.TP +.B --version Display the library and kernel driver version. -.br . .SH COMMANDS . @@ -656,7 +615,7 @@ Flags defaults to read-write (rw) or may be read-only (ro). Uuid, minor number and flags are optional so those fields may be empty. A semi-colon separates specifications of different devices. Use a backslash to escape the following character, for example a comma or semi-colon in a name or table. See also CONCISE FORMAT below. -. +. .HP .CMD_DEPS .br @@ -701,11 +660,11 @@ Fields are comma-separated and chosen from the following list: .BR events , .BR uuid . Attributes are: -.RI ( L )ive, -.RI ( I )nactive, -.RI ( s )uspended, -.RI ( r )ead-only, -.RI read-( w )rite. +.RB ( L )ive, +.RB ( I )nactive, +.RB ( s )uspended, +.RB ( r )ead-only, +.RB read-( w )rite. Precede the list with '\fB+\fP' to append to the default selection of columns instead of replacing it. Precede any sort field with '\fB-\fP' for a reverse sort on that column. @@ -838,7 +797,7 @@ Outputs status information for each of the device's targets. With \fB--target\fP, only information relating to the specified target type any is displayed. With \fB--noflush\fP, the thin target (from version 1.3.0) doesn't commit any outstanding changes to disk before reporting its statistics. - +. .HP .CMD_SUSPEND .br @@ -964,14 +923,13 @@ Creates a striped area. e.g. striped 2 32 /dev/hda1 0 /dev/hdb1 0 will map the first chunk (16k) as follows: .RS -.RS +.IP LV chunk 1 -> hda1, chunk 1 LV chunk 2 -> hdb1, chunk 1 LV chunk 3 -> hda1, chunk 2 LV chunk 4 -> hdb1, chunk 2 etc. .RE -.RE .TP .B error Errors any I/O that goes to this area. Useful for testing or diff --git a/man/dmstats.8_main b/man/dmstats.8_main index db9f31904..f77ca05c8 100644 --- a/man/dmstats.8_main +++ b/man/dmstats.8_main @@ -1,12 +1,12 @@ .TH DMSTATS 8 "Jun 23 2016" "Linux" "MAINTENANCE COMMANDS" - +. .de OPT_PROGRAMS -. RB \%[ --allprograms | --programid +. RB [ --allprograms | --programid . IR id ] .. . .de OPT_REGIONS -. RB \%[ --allregions | --regionid +. RB [ --allregions | --regionid . IR id ] .. .de OPT_OBJECTS @@ -55,15 +55,17 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_COMMAND . ad l +. nh . IR command -. IR device_name " |" +. IR device_name \ | . BR --major . IR major . BR --minor -. IR minor " |" +. IR minor \ | . BR -u | --uuid . IR uuid -. RB \%[ -v | --verbose] +. RB [ -v | --verbose ] +. hy . ad b .. .CMD_COMMAND @@ -72,10 +74,12 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_CLEAR . ad l +. nh . BR clear . IR device_name . OPT_PROGRAMS . OPT_REGIONS +. hy . ad b .. .CMD_CLEAR @@ -84,13 +88,14 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_CREATE . ad l +. nh . BR create . IR device_name... | file_path... | \fB--alldevices . RB [ --areas . IR nr_areas | \fB--areasize . IR area_size ] . RB [ --bounds -. IR \%histogram_boundaries ] +. IR histogram_boundaries ] . RB [ --filemap ] . RB [ --follow . IR follow_mode ] @@ -102,10 +107,11 @@ dmstats \(em device-mapper statistics management . IR start_sector . BR --length . IR length | \fB--segments ] -. RB \%[ --userdata +. RB [ --userdata . IR user_data ] . RB [ --programid . IR id ] +. hy . ad b .. .CMD_CREATE @@ -114,10 +120,12 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_DELETE . ad l +. nh . BR delete . IR device_name | \fB--alldevices . OPT_PROGRAMS . OPT_REGIONS +. hy . ad b .. .CMD_DELETE @@ -126,12 +134,14 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_GROUP . ad l +. nh . BR group . RI [ device_name | \fB--alldevices ] . RB [ --alias . IR name ] . RB [ --regions . IR regions ] +. hy . ad b .. .CMD_GROUP @@ -149,6 +159,7 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_LIST . ad l +. nh . BR list . RI [ device_name ] . RB [ --histogram ] @@ -156,9 +167,10 @@ dmstats \(em device-mapper statistics management . RB [ --units . IR units ] . OPT_OBJECTS -. RB \%[ --nosuffix ] +. RB [ --nosuffix ] . RB [ --notimesuffix ] -. RB \%[ -v | --verbose] +. RB [ -v | --verbose ] +. hy . ad b .. .CMD_LIST @@ -167,11 +179,13 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_PRINT . ad l +. nh . BR print . RI [ device_name ] . RB [ --clear ] . OPT_PROGRAMS . OPT_REGIONS +. hy . ad b .. .CMD_PRINT @@ -180,6 +194,7 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_REPORT . ad l +. nh . BR report . RI [ device_name ] . RB [ --interval @@ -199,7 +214,8 @@ dmstats \(em device-mapper statistics management . RB [ --units . IR units ] . RB [ --nosuffix ] -. RB \%[ --notimesuffix ] +. RB [ --notimesuffix ] +. hy . ad b .. .CMD_REPORT @@ -207,10 +223,12 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_UNGROUP . ad l +. nh . BR ungroup . RI [ device_name | \fB--alldevices ] . RB [ --groupid . IR id ] +. hy . ad b .. .CMD_UNGROUP @@ -218,6 +236,7 @@ dmstats \(em device-mapper statistics management .B dmstats .de CMD_UPDATE_FILEMAP . ad l +. nh . BR update_filemap . IR file_path . RB [ --groupid @@ -225,6 +244,7 @@ dmstats \(em device-mapper statistics management . RB [ --follow . IR follow_mode ] . OPT_FOREGROUND +. hy . ad b .. .CMD_UPDATE_FILEMAP @@ -237,334 +257,272 @@ dmstats \(em device-mapper statistics management The dmstats program manages IO statistics regions for devices that use the device-mapper driver. Statistics regions may be created, deleted, listed and reported on using the tool. - +.P The first argument to dmstats is a \fIcommand\fP. - +.P The second argument is the \fIdevice name\fP, \fIuuid\fP or \fImajor\fP and \fIminor\fP numbers. - +.P Further options permit the selection of regions, output format control, and reporting behaviour. - +.P When no device argument is given dmstats will by default operate on all device-mapper devices present. The \fBcreate\fP and \fBdelete\fP commands require the use of \fB--alldevices\fP when used in this way. . .SH OPTIONS . -.HP -.BR --alias -.IR name -.br +.TP +.B --alias \fIname Specify an alias name for a group. . -.HP -.BR --alldevices -.br +.TP +.B --alldevices If no device arguments are given allow operation on all devices when creating or deleting regions. . -.HP -.BR --allprograms -.br +.TP +.B --allprograms Include regions from all program IDs for list and report operations. -.br -.HP -.BR --allregions -.br +. +.TP +.B --allregions Include all present regions for commands that normally accept a single region identifier. . -.HP -.BR --area -.br +.TP +.B --area When peforming a list or report, include objects of type area in the results. . -.HP -.BR --areas -.IR nr_areas -.br +.TP +.B --areas \fInr_areas Specify the number of statistics areas to create within a new region. . -.HP -.BR --areasize -.IR area_size \c -.RB [ \c +.TP +.B --areasize \fIarea_size\fR[\c .UNITS -.br Specify the size of areas into which a new region should be divided. An optional suffix selects units of: .HELP_UNITS . -.HP -.BR --clear -.br +.TP +.B --clear When printing statistics counters, also atomically reset them to zero. . -.HP -.BR --count -.IR count -.br +.TP +.B --count \fIcount Specify the iteration count for repeating reports. If the count argument is zero reports will continue to repeat until interrupted. . -.HP -.BR --group -.br +.TP +.B --group When peforming a list or report, include objects of type group in the results. . -.HP -.BR --filemap -.br +.TP +.B --filemap Instead of creating regions on a device as specified by command line options, open the file found at each \fBfile_path\fP argument, and create regions corresponding to the locations of the on-disk extents allocated to the file(s). . -.HP -.BR --nomonitor -.br +.TP +.B --nomonitor Disable the \fBdmfilemapd\fP daemon when creating new file mapped groups. Normally the device-mapper filemap monitoring daemon, \fBdmfilemapd\fP, is started for each file mapped group to update the set of regions as the file changes on-disk: use of this option disables this behaviour. - +.P Regions in the group may still be updated with the \fBupdate_filemap\fP command, or by starting the daemon manually. . -.HP -.BR --follow -.IR follow_mode -.br +.TP +.B --follow \fIfollow_mode Specify the \fBdmfilemapd\fP file following mode. The file map monitoring daemon can monitor files in two distinct ways: the mode affects the behaviour of the daemon when a file under monitoring is renamed or unlinked, and the conditions which cause the daemon to terminate. - +.P The \fBfollow_mode\fP argument is either "inode", for follow-inode mode, or "path", for follow-path. - +.P If follow-inode mode is used, the daemon will hold the file open, and continue to update regions from the same file descriptor. This means that the mapping will follow rename, move (within the same file system), and unlink operations. This mode is useful if the file is expected to be moved, renamed, or unlinked while it is being monitored. - +.P In follow-inode mode, the daemon will exit once it detects that the file has been unlinked and it is the last holder of a reference to it. - +.P If follow-path is used, the daemon will re-open the provided path on each monitoring iteration. This means that the group will be updated to reflect a new file being moved to the same path as the original file. This mode is useful for files that are expected to be updated via unlink and rename. - +.P In follow-path mode, the daemon will exit if the file is removed and not replaced within a brief tolerance interval. - +.P In either mode, the daemon exits automatically if the monitored group is removed. . -.HP -.BR --foreground -.br +.TP +.B --foreground Specify that the \fBdmfilemapd\fP daemon should run in the foreground. The daemon will not fork into the background, and will replace the \fBdmstats\fP command that started it. . -.HP -.BR --groupid -.IR id -.br +.TP +.B --groupid \fIid Specify the group to operate on. . -.HP -.BR --bounds -.IR histogram_boundaries \c +.TP +.B --bounds \fIhistogram_boundaries\c .RB [ ns | us | ms | s ] -.br Specify the boundaries of a latency histogram to be tracked for the region as a comma separated list of latency values. Latency values are given in nanoseconds. An optional unit suffix of -.BR ns , -.BR us , -.BR ms , +.BR ns , us , ms , or \fBs\fP may be given after each value to specify units of nanoseconds, microseconds, miliseconds or seconds respectively. . -.HP -.BR --histogram -.br +.TP +.B --histogram When used with the \fBreport\fP and \fBlist\fP commands select default fields that emphasize latency histogram data. . -.HP -.BR --interval -.IR seconds -.br +.TP +.B --interval \fIseconds Specify the interval in seconds between successive iterations for repeating reports. If \fB--interval\fP is specified but \fB--count\fP is not, reports will continue to repeat until interrupted. . -.HP -.BR --length -.IR length \c -.RB [ \c +.TP +.B --length \fIlength\fR[\c .UNITS -.br Specify the length of a new statistics region in sectors. An optional suffix selects units of: .HELP_UNITS . -.HP -.BR -j | --major -.IR major -.br +.TP +.BR -j | --major " " \fImajor Specify the major number. . -.HP -.BR -m | --minor -.IR minor -.br +.TP +.BR -m | --minor " " \fIminor Specify the minor number. . -.HP -.BR --nogroup -.br +.TP +.B --nogroup When creating regions mapping the extents of a file in the file system, do not create a group or set an alias. . -.HP -.BR --nosuffix -.br +.TP +.B --nosuffix Suppress the suffix on output sizes. Use with \fB--units\fP (except h and H) if processing the output. . -.HP -.BR --notimesuffix -.br +.TP +.B --notimesuffix Suppress the suffix on output time values. Histogram boundary values will be reported in units of nanoseconds. . -.HP +.TP .BR -o | --options -.br Specify which report fields to display. . -.HP -.BR -O | --sort -.IR sort_fields -.br +.TP +.BR -O | --sort " " \fIsort_fields Sort output according to the list of fields given. Precede any sort field with '\fB-\fP' for a reverse sort on that column. . -.HP -.BR --precise -.br +.TP +.B --precise Attempt to use nanosecond precision counters when creating new statistics regions. . -.HP -.BR --programid -.IR id -.br +.TP +.B --programid \fIid Specify a program ID string. When creating new statistics regions this string is stored with the region. Subsequent operations may supply a program ID in order to select only regions with a matching value. The default program ID for dmstats-managed regions is "dmstats". . -.HP -.BR --region -.br +.TP +.B --region When peforming a list or report, include objects of type region in the results. . -.HP -.BR --regionid -.IR id -.br +.TP +.B --regionid \fIid Specify the region to operate on. . -.HP -.BR --regions -.IR region_list -.br +.TP +.B --regions \fIregion_list Specify a list of regions to group. The group list is a comma-separated list of region identifiers. Continuous sequences of identifiers may be expressed as a hyphen separated range, for example: '1-10'. . -.HP -.BR --relative -.br +.TP +.B --relative If displaying the histogram report show relative (percentage) values instead of absolute counts. . -.HP -.BR -S | --select -.IR selection -.br +.TP +.BR -S | --select " " \fIselection Display only rows that match \fIselection\fP criteria. All rows with the additional "selected" column (\fB-o selected\fP) showing 1 if the row matches the \fIselection\fP and 0 otherwise. The selection criteria are defined by specifying column names and their valid values while making use of supported comparison operators. . -.HP -.BR --start -.IR start \c -.RB [ \c +.TP +.B --start \fIstart\fR[\c .UNITS -.br Specify the start offset of a new statistics region in sectors. An optional suffix selects units of: .HELP_UNITS . -.HP -.BR --segments -.br +.TP +.B --segments When used with \fBcreate\fP, create a new statistics region for each target contained in the given device(s). This causes a separate region to be allocated for each segment of the device. - +.P The newly created regions are automatically placed into a group unless the \fB--nogroup\fP option is given. When grouping is enabled a group alias may be specified using the \fB--alias\fP option. . -.HP -.BR --units +.TP +.B --units \c .RI [ units ] \c .RB [ h | H | \c .UNITS -.br Set the display units for report output. All sizes are output in these units: .RB ( h )uman-readable, .HELP_UNITS Can also specify custom units e.g. \fB--units\ 3M\fP. . -.HP -.BR --userdata -.IR user_data -.br +.TP +.B --userdata \fIuser_data Specify user data (a word) to be stored with a new region. The value is added to any internal auxiliary data (for example, group information), and stored with the region in the aux_data field provided by the kernel. Whitespace is not permitted. . -.HP +.TP .BR -u | --uuid -.br Specify the uuid. . -.HP -.BR -v | --verbose " [" -v | --verbose ] -.br +.TP +.BR -v | --verbose \ [ -v | --verbose ] Produce additional output. . .SH COMMANDS @@ -579,23 +537,23 @@ regions (with the exception of in-flight IO counters). .CMD_CREATE .br Creates one or more new statistics regions on the specified device(s). - +.P The region will span the entire device unless \fB--start\fP and \fB--length\fP or \fB--segments\fP are given. The \fB--start\fP an \fB--length\fP options allow a region of arbitrary length to be placed at an arbitrary offset into the device. The \fB--segments\fP option causes a new region to be created for each target in the corresponding device-mapper device's table. - +.P If the \fB--precise\fP option is used the command will attempt to create a region using nanosecond precision counters. - +.P If \fB--bounds\fP is given a latency histogram will be tracked for the new region. The boundaries of the histogram bins are given as a comma separated list of latency values. There is an implicit lower bound of zero on the first bin and an implicit upper bound of infinity (or the configured interval duration) on the final bin. - +.P Latencies are given in nanoseconds. An optional unit suffix of ns, us, ms, or s may be given after each value to specify units of nanoseconds, microseconds, miliseconds or seconds respectively, so for example, 10ms @@ -603,19 +561,19 @@ is equivalent to 10000000. Latency values with a precision of less than one milisecond can only be used when precise timestamps are enabled: if \fB--precise\fP is not given and values less than one milisecond are used it will be enabled automatically. - +.P An optional \fBprogram_id\fP or \fBuser_data\fP string may be associated with the region. A \fBprogram_id\fP may then be used to select regions for subsequent list, print, and report operations. The \fBuser_data\fP stores an arbitrary string and is not used by dmstats or the device-mapper kernel statistics subsystem. - +.P By default dmstats creates regions with a \fBprogram_id\fP of "dmstats". - +.P On success the \fBregion_id\fP of the newly created region is printed to stdout. - +.P If the \fB--filemap\fP option is given with a regular file, or list of files, as the \fBfile_path\fP argument, instead of creating regions with parameters specified on the command line, \fBdmstats\fP will open @@ -623,20 +581,20 @@ the files located at \fBfile_path\fP and create regions corresponding to the physical extents allocated to the file. This can be used to monitor statistics for individual files in the file system, for example, virtual machine images, swap areas, or large database files. - +.P To work with the \fB--filemap\fP option, files must be located on a local file system, backed by a device-mapper device, that supports physical extent data using the FIEMAP ioctl (Ext4 and XFS for e.g.). - +.P By default regions that map a file are placed into a group and the group alias is set to the basename of the file. This behaviour can be overridden with the \fB--alias\fP and \fB--nogroup\fP options. - +.P Creating a group that maps a file automatically starts a daemon, \fBdmfilemapd\fP to monitor the file and update the mapping as the extents allocated to the file change. This behaviour can be disabled using the \fB--nomonitor\fP option. - +.P Use the \fB--group\fP option to only display information for groups when listing and reporting. . @@ -646,17 +604,17 @@ when listing and reporting. Delete the specified statistics region. All counters and resources used by the region are released and the region will not appear in the output of subsequent list, print, or report operations. - +.P All regions registered on a device may be removed using \fB--allregions\fP. - +.P To remove all regions on all devices both \fB--allregions\fP and \fB--alldevices\fP must be used. - +.P If a \fB--groupid\fP is given instead of a \fB--regionid\fP the command will attempt to delete the group and all regions that it contains. - +.P If a deleted region is the first member of a group of regions the group will also be removed. . @@ -665,19 +623,19 @@ will also be removed. .br Combine one or more statistics regions on the specified device into a group. - +.P The list of regions to be grouped is specified with \fB--regions\fP and an optional alias may be assigned with \fB--alias\fP. The set of regions is given as a comma-separated list of region identifiers. A continuous range of identifers spanning from \fBR1\fP to \fBR2\fP may be expressed as '\fBR1\fP-\fBR2\fP'. - +.P Regions that have a histogram configured can be grouped: in this case the number of histogram bins and their bounds must match exactly. - +.P On success the group list and newly created \fBgroup_id\fP are printed to stdout. - +.P The group metadata is stored with the first (lowest numbered) \fBregion_id\fP in the group: deleting this region will also delete the group and other group members will be returned to their prior @@ -695,18 +653,18 @@ the list of report fields. List the statistics regions, areas, or groups registered on the device. If the \fB--allprograms\fP switch is given all regions will be listed regardless of region program ID values. - +.P By default only regions and groups are included in list output. If \fB-v\fP or \fB--verbose\fP is given the report will also include a row of information for each configured group and for each area contained in each region displayed. - +.P Regions that contain a single area are by default omitted from the verbose list since their properties are identical to the area that they contain - to view all regions regardless of the number of areas present use \fB--region\fP). To also view the areas contained within regions use \fB--area\fP. - +.P If \fB--histogram\fP is given the report will include the bin count and latency boundary values for any configured histograms. .HP @@ -722,16 +680,16 @@ Start a report for the specified object or for all present objects. If the count argument is specified, the report will repeat at a fixed interval set by the \fB--interval\fP option. The default interval is one second. - +.P If the \fB--allprograms\fP switch is given, all regions will be listed, regardless of region program ID values. - +.P If the \fB--histogram\fP is given the report will include the histogram values and latency boundaries. - +.P If the \fB--relative\fP is used the default histogram field displays bin values as a percentage of the total number of I/Os. - +.P Object types (areas, regions and groups) to include in the report are selected using the \fB--area\fP, \fB--region\fP, and \fB--group\fP options. @@ -741,7 +699,7 @@ options. .br Remove an existing group and return all the group's regions to their original state. - +.P The group to be removed is specified using \fB--groupid\fP. .HP .CMD_UPDATE_FILEMAP @@ -749,19 +707,19 @@ The group to be removed is specified using \fB--groupid\fP. Update a group of \fBdmstats\fP regions specified by \fBgroup_id\fP, that were previously created with \fB--filemap\fP, either directly, or by starting the monitoring daemon, \fBdmfilemapd\fP. - +.P This will add and remove regions to reflect changes in the allocated extents of the file on-disk, since the time that it was crated or last updated. - +.P Use of this command is not normally needed since the \fBdmfilemapd\fP daemon will automatically monitor filemap groups and perform these updates when required. - +.P If a filemapped group was created with \fB--nomonitor\fP, or the daemon has been killed, the \fBupdate_filemap\fP can be used to manually force an update or start a new daemon. - +.P Use \fB--nomonitor\fP to force a direct update and disable starting the monitoring daemon. . @@ -773,55 +731,54 @@ span any range: from a single sector to the whole device. A region may be further sub-divided into a number of distinct areas (one or more), each with its own counter set. In this case a summary value for the entire region is also available for use in reports. - +.P In addition, one or more regions on one device can be combined into a statistics group. Groups allow several regions to be aggregated and reported as a single entity; counters for all regions and areas are summed and used to report totals for all group members. Groups also permit the assignment of an optional alias, allowing meaningful names to be associated with sets of regions. - +.P The group metadata is stored with the first (lowest numbered) \fBregion_id\fP in the group: deleting this region will also delete the group and other group members will be returned to their prior state. - +.P By default new regions span the entire device. The \fB--start\fP and \fB--length\fP options allows a region of any size to be placed at any location on the device. - +.P Using offsets it is possible to create regions that map individual objects within a block device (for example: partitions, files in a file system, or stripes or other structures in a RAID volume). Groups allow several non-contiguous regions to be assembled together for reporting and data aggregation. - +.P A region may be either divided into the specified number of equal-sized areas, or into areas of the given size by specifying one of \fB--areas\fP or \fB--areasize\fP when creating a region with the \fBcreate\fP command. Depending on the size of the areas and the device region the final area within the region may be smaller than requested. -.P -.B Region identifiers -.P +. +.SS Region identifiers +. Each region is assigned an identifier when it is created that is used to reference the region in subsequent operations. Region identifiers are unique within a given device (including across different \fBprogram_id\fP values). - +.P Depending on the sequence of create and delete operations, gaps may exist in the sequence of \fBregion_id\fP values for a particular device. - +.P The \fBregion_id\fP should be treated as an opaque identifier used to reference the region. . -.P -.B Group identifiers -.P +.SS Group identifiers +. Groups are also assigned an integer identifier at creation time; like region identifiers, group identifiers are unique within the containing device. - +.P The \fBgroup_id\fP should be treated as an opaque identifier used to reference the group. . @@ -832,82 +789,80 @@ correspond to the extents of a file in the file system. This allows IO statistics to be monitored on a per-file basis, for example to observe large database files, virtual machine images, or other files of interest. - +.P To be able to use file mapping, the file must be backed by a device-mapper device, and in a file system that supports the FIEMAP ioctl (and which returns data describing the physical location of extents). This currently includes \fBxfs(5)\fP and \fBext4(5)\fP. - +.P By default the regions making up a file are placed together in a group, and the group alias is set to the \fBbasename(3)\fP of the file. This allows statistics to be reported for the file as a whole, aggregating values for the regions making up the group. To see only the whole file (group) when using the \fBlist\fP and \fBreport\fP commands, use \fB--group\fP. - +.P Since it is possible for the file to change after the initial group of regions is created, the \fBupdate_filemap\fP command, and \fBdmfilemapd\fP daemon are provided to update file mapped groups either manually or automatically. . -.P -.B File follow modes -.P +.SS File follow modes +. The file map monitoring daemon can monitor files in two distinct ways: follow-inode mode, and follow-path mode. - +.P The mode affects the behaviour of the daemon when a file under monitoring is renamed or unlinked, and the conditions which cause the daemon to terminate. - +.P If follow-inode mode is used, the daemon will hold the file open, and continue to update regions from the same file descriptor. This means that the mapping will follow rename, move (within the same file system), and unlink operations. This mode is useful if the file is expected to be moved, renamed, or unlinked while it is being monitored. - +.P In follow-inode mode, the daemon will exit once it detects that the file has been unlinked and it is the last holder of a reference to it. - +.P If follow-path is used, the daemon will re-open the provided path on each monitoring iteration. This means that the group will be updated to reflect a new file being moved to the same path as the original file. This mode is useful for files that are expected to be updated via unlink and rename. - +.P In follow-path mode, the daemon will exit if the file is removed and not replaced within a brief tolerance interval (one second). - +.P To stop the daemon, delete the group containing the mapped regions: the daemon will automatically shut down. - +.P The daemon can also be safely killed at any time and the group kept: if the file is still being allocated the mapping will become progressively out-of-date as extents are added and removed (in this case the daemon can be re-started or the group updated manually with the \fBupdate_filemap\fP command). - +.P See the \fBcreate\fP command and \fB--filemap\fP, \fB--follow\fP, and \fB--nomonitor\fP options for further information. . -.P -.B Limitations -.P +.SS Limitations +. The daemon attempts to maintain good synchronisation between the file extents and the regions contained in the group, however, since it can only react to new allocations once they have been written, there are inevitably some IO events that cannot be counted when a file is growing, particularly if the file is being extended by a single thread writing beyond end-of-file (for example, the \fBdd\fP program). - +.P There is a further loss of events in that there is currently no way to atomically resize a \fBdmstats\fP region and preserve its current counter values. This affects files when they grow by extending the final extent, rather than allocating a new extent: any events that had accumulated in the region between any prior operation and the resize are lost. - +.P File mapping is currently most effective in cases where the majority of IO does not trigger extent allocation. Future updates may address these limitations when kernel support is available. @@ -916,7 +871,7 @@ these limitations when kernel support is available. . The dmstats report provides several types of field that may be added to the default field set, or used to create custom reports. - +.P All performance counters and metrics are calculated per-area. . .SS Derived metrics @@ -1273,12 +1228,11 @@ Bryn M. Reeves <bmr@redhat.com> .SH SEE ALSO . .BR dmsetup (8) - +.P LVM2 resource page: https://www.sourceware.org/lvm2/ .br Device-mapper resource page: http://sources.redhat.com/dm/ -.br - +.P Device-mapper statistics kernel documentation .br .I Documentation/device-mapper/statistics.txt diff --git a/man/fsadm.8_main b/man/fsadm.8_main index 799cb2547..d83e99292 100644 --- a/man/fsadm.8_main +++ b/man/fsadm.8_main @@ -1,24 +1,27 @@ .TH "FSADM" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" +. .SH "NAME" +. fsadm \(em utility to resize or check filesystem on a device +. .SH SYNOPSIS . .PD 0 .ad l -.HP 5 +.TP 6 .B fsadm .RI [ options ] .BR check .IR device . -.HP +.TP .B fsadm .RI [ options ] .BR resize .IR device .RI [ new_size ] -.PD .ad b +.PD . .SH DESCRIPTION . @@ -34,44 +37,36 @@ filesystem. . .SH OPTIONS . -.HP +.TP .BR -e | --ext-offline -.br Unmount ext2/ext3/ext4 filesystem before doing resize. . -.HP +.TP .BR -f | --force -.br Bypass some sanity checks. . -.HP +.TP .BR -h | --help -.br Display the help text. . -.HP +.TP .BR -n | --dry-run -.br Print commands without running them. . -.HP +.TP .BR -v | --verbose -.br Be more verbose. . -.HP +.TP .BR -y | --yes -.br Answer "yes" at any prompts. . -.HP +.TP .BR -c | --cryptresize -.br Resize dm-crypt mapping together with filesystem detected on the device. The dm-crypt device must be recognizable by cryptsetup(8). . -.HP +.TP .BR \fInew_size [ B | K | M | G | T | P | E ] -.br Absolute number of filesystem blocks to be in the filesystem, or an absolute size using a suffix (in powers of 1024). If new_size is not supplied, the whole device is used. @@ -91,30 +86,37 @@ Resize the filesystem on logical volume \fI/dev/vg/test\fP to 1000 megabytes. If \fI/dev/vg/test\fP contains ext2/ext3/ext4 filesystem it will be unmounted prior the resize. All [y/n] questions will be answered 'y'. -.sp +.P +# .B fsadm -e -y resize /dev/vg/test 1000M . .SH ENVIRONMENT VARIABLES . .TP -.B "TMPDIR " +.B TMPDIR The temporary directory name for mount points. Defaults to "\fI/tmp\fP". .TP .B DM_DEV_DIR The device directory name. Defaults to "\fI/dev\fP" and must be an absolute path. - +. .SH SEE ALSO +. .nh +.ad l .BR lvm (8), .BR lvresize (8), .BR lvm.conf (5), +.P .BR fsck (8), .BR tune2fs (8), .BR resize2fs (8), +.P .BR reiserfstune (8), .BR resize_reiserfs (8), +.P .BR xfs_info (8), .BR xfs_growfs (8), .BR xfs_check (8), +.P .BR cryptsetup (8) diff --git a/man/lvm.8_main b/man/lvm.8_main index b221761e3..44961f7cf 100644 --- a/man/lvm.8_main +++ b/man/lvm.8_main @@ -11,7 +11,6 @@ lvm \(em LVM2 tools . .SH DESCRIPTION . - The Logical Volume Manager (LVM) provides tools to create virtual block devices from physical devices. Virtual devices may be easier to manage than physical devices, and can have capabilities beyond what the physical @@ -22,7 +21,6 @@ applications. Each block of data in an LV is stored on one or more PV in the VG, according to algorithms implemented by Device Mapper (DM) in the kernel. .P - The lvm command, and other commands listed below, are the command-line tools for LVM. A separate manual page describes each command in detail. .P @@ -40,7 +38,7 @@ On invocation, \fBlvm\fP requires that only the standard file descriptors stdin, stdout and stderr are available. If others are found, they get closed and messages are issued warning about the leak. This warning can be suppressed by setting the environment variable -.B LVM_SUPPRESS_FD_WARNINGS\fP. +.BR LVM_SUPPRESS_FD_WARNINGS . .P Where commands take VG or LV names as arguments, the full path name is optional. An LV called "lvol0" in a VG called "vg0" can be specified @@ -67,7 +65,7 @@ The following commands are built into lvm without links normally being created in the filesystem for them. .sp .PD 0 -.TP 14 +.TP 16 .B config The same as \fBlvmconfig\fP(8) below. .TP @@ -112,7 +110,7 @@ Display version information. The following commands implement the core LVM functionality. .sp .PD 0 -.TP 14 +.TP 16 .B pvchange Change attributes of a Physical Volume. .TP @@ -296,19 +294,18 @@ original VG, LV and internal layer names. . .SH UNIQUE NAMES . - VG names should be unique. vgcreate will produce an error if the specified VG name matches an existing VG name. However, there are cases where different VGs with the same name can appear to LVM, e.g. after moving disks or changing filters. - +.P When VGs with the same name exist, commands operating on all VGs will include all of the VGs with the same name. If the ambiguous VG name is specified on the command line, the command will produce an error. The error states that multiple VGs exist with the specified name. To process one of the VGs specifically, the --select option should be used with the -UUID of the intended VG: '--select vg_uuid=<uuid>'. - +UUID of the intended VG: --select vg_uuid=<uuid> +.P An exception is if all but one of the VGs with the shared name is foreign (see .BR lvmsystemid (7).) @@ -317,18 +314,17 @@ VG and is processed. .P LV names are unique within a VG. The name of an historical LV cannot be reused until the historical LV has itself been removed or renamed. - . .SH ALLOCATION . When an operation needs to allocate Physical Extents for one or more Logical Volumes, the tools proceed as follows: - +.P First of all, they generate the complete set of unallocated Physical Extents in the Volume Group. If any ranges of Physical Extents are supplied at the end of the command line, only unallocated Physical Extents within those ranges on the specified Physical Volumes are considered. - +.P Then they try each allocation policy in turn, starting with the strictest policy (\fBcontiguous\fP) and ending with the allocation policy specified using \fB--alloc\fP or set as the default for the particular Logical @@ -337,14 +333,14 @@ lowest-numbered Logical Extent of the empty Logical Volume space that needs to be filled, they allocate as much space as possible according to the restrictions imposed by the policy. If more space is needed, they move on to the next policy. - +.P The restrictions are as follows: - +.P \fBContiguous\fP requires that the physical location of any Logical Extent that is not the first Logical Extent of a Logical Volume is adjacent to the physical location of the Logical Extent immediately preceding it. - +.P \fBCling\fP requires that the Physical Volume used for any Logical Extent to be added to an existing Logical Volume is already in use by at least one Logical Extent earlier in that Logical Volume. If the @@ -353,31 +349,31 @@ Physical Volumes are considered to match if any of the listed tags is present on both Physical Volumes. This allows groups of Physical Volumes with similar properties (such as their physical location) to be tagged and treated as equivalent for allocation purposes. - +.P When a Logical Volume is striped or mirrored, the above restrictions are applied independently to each stripe or mirror image (leg) that needs space. - +.P \fBNormal\fP will not choose a Physical Extent that shares the same Physical Volume as a Logical Extent already allocated to a parallel Logical Volume (i.e. a different stripe or mirror image/leg) at the same offset within that parallel Logical Volume. - +.P When allocating a mirror log at the same time as Logical Volumes to hold the mirror data, Normal will first try to select different Physical Volumes for the log and the data. If that's not possible and the .B allocation/mirror_logs_require_separate_pvs configuration parameter is set to 0, it will then allow the log to share Physical Volume(s) with part of the data. - +.P When allocating thin pool metadata, similar considerations to those of a mirror log in the last paragraph apply based on the value of the .B allocation/thin_pool_metadata_require_separate_pvs configuration parameter. - +.P If you rely upon any layout behaviour beyond that documented here, be aware that it might change in future versions of the code. - +.P For example, if you supply on the command line two empty Physical Volumes that have an identical number of free Physical Extents available for allocation, the current code considers using each of them in the order @@ -387,7 +383,7 @@ for a particular Logical Volume, then you should build it up through a sequence of \fBlvcreate\fP(8) and \fBlvconvert\fP(8) steps such that the restrictions described above applied to each step leave the tools no discretion over the layout. - +.P To view the way the allocation process currently works in any specific case, read the debug logging output, for example by adding \fB-vvvv\fP to a command. @@ -501,7 +497,7 @@ Prepends source file name and code line number with libdm debugging. .BR lvm (8), .BR lvm.conf (5), .BR lvmconfig (8), - +.P .BR pvchange (8), .BR pvck (8), .BR pvcreate (8), @@ -511,7 +507,7 @@ Prepends source file name and code line number with libdm debugging. .BR pvresize (8), .BR pvs (8), .BR pvscan (8), - +.P .BR vgcfgbackup (8), .BR vgcfgrestore (8), .BR vgchange (8), @@ -531,7 +527,7 @@ Prepends source file name and code line number with libdm debugging. .BR vgs (8), .BR vgscan (8), .BR vgsplit (8), - +.P .BR lvcreate (8), .BR lvchange (8), .BR lvconvert (8), @@ -543,26 +539,26 @@ Prepends source file name and code line number with libdm debugging. .BR lvresize (8), .BR lvs (8), .BR lvscan (8), - +.P .BR lvm-fullreport (8), .BR lvm-lvpoll (8), .BR lvm2-activation-generator (8), .BR blkdeactivate (8), .BR lvmdump (8), - +.P .BR dmeventd (8), .BR lvmpolld (8), .BR lvmlockd (8), .BR lvmlockctl (8), .BR cmirrord (8), .BR lvmdbusd (8), - +.P .BR lvmsystemid (7), .BR lvmreport (7), .BR lvmraid (7), .BR lvmthin (7), .BR lvmcache (7), - +.P .BR dmsetup (8), .BR dmstats (8), .BR readline (3) diff --git a/man/lvm.conf.5_main b/man/lvm.conf.5_main index 3a45f1ce0..63945ea2f 100644 --- a/man/lvm.conf.5_main +++ b/man/lvm.conf.5_main @@ -1,28 +1,35 @@ .TH LVM.CONF 5 "LVM TOOLS #VERSION#" "Red Hat, Inc." \" -*- nroff -*- +. .SH NAME +. lvm.conf \(em Configuration file for LVM2 +. .SH SYNOPSIS +. .B #DEFAULT_SYS_DIR#/lvm.conf +. .SH DESCRIPTION +. \fBlvm.conf\fP is loaded during the initialisation phase of \fBlvm\fP(8). This file can in turn lead to other files being loaded - settings read in later override earlier settings. File timestamps are checked between commands and if any have changed, all the files are reloaded. - +.P For a description of each lvm.conf setting, run: - +.P .B lvmconfig --typeconfig default --withcomments --withspaces - +.P The settings defined in lvm.conf can be overridden by any of these extended configuration methods: +. .TP .B direct config override on command line The \fB--config ConfigurationString\fP command line option takes the ConfigurationString as direct string representation of the configuration to override the existing configuration. The ConfigurationString is of exactly the same format as used in any LVM configuration file. - +. .TP .B profile config .br @@ -30,17 +37,17 @@ A profile is a set of selected customizable configuration settings that are aimed to achieve a certain characteristics in various environments or uses. It's used to override existing configuration. Normally, the name of the profile should reflect that environment or use. - +.P There are two groups of profiles recognised: \fBcommand profiles\fP and \fBmetadata profiles\fP. - +.P The \fBcommand profile\fP is used to override selected configuration settings at global LVM command level - it is applied at the very beginning of LVM command execution and it is used throughout the whole time of LVM command execution. The command profile is applied by using the \fB--commandprofile ProfileName\fP command line option that is recognised by all LVM2 commands. - +.P The \fBmetadata profile\fP is used to override selected configuration settings at Volume Group/Logical Volume level - it is applied independently for each Volume Group/Logical Volume that is being processed. As such, @@ -56,12 +63,12 @@ option during creation when using \fBvgcreate\fP or \fBlvcreate\fP command. The \fBvgs\fP and \fBlvs\fP reporting commands provide \fB-o vg_profile\fP and \fB-o lv_profile\fP output options to show the metadata profile currently attached to a Volume Group or a Logical Volume. - +.P The set of options allowed for command profiles is mutually exclusive when compared to the set of options allowed for metadata profiles. The settings that belong to either of these two sets can't be mixed together and LVM tools will reject such profiles. - +.P LVM itself provides a few predefined configuration profiles. Users are allowed to add more profiles with different values if needed. For this purpose, there's the \fBcommand_profile_template.profile\fP @@ -74,31 +81,36 @@ or \fBlvmconfig --file <ProfileName.profile> --type profilable-metadata <section can be used to generate a configuration with profilable settings in either of the type for given section and save it to new ProfileName.profile (if the section is not specified, all profilable settings are reported). - -The profiles are stored in #DEFAULT_PROFILE_DIR# directory by default. +.P +The profiles are stored in \fI#DEFAULT_PROFILE_DIR#\fP directory by default. This location can be changed by using the \fBconfig/profile_dir\fP setting. Each profile configuration is stored in \fBProfileName.profile\fP file in the profile directory. When referencing the profile, the \fB.profile\fP suffix is left out. - +. .TP .B tag config .br See \fBtags\fP configuration setting description below. - -.LP +.P When several configuration methods are used at the same time and when LVM looks for the value of a particular setting, it traverses this \fBconfig cascade\fP from left to right: - -\fBdirect config override on command line\fP -> \fBcommand profile config\fP -> \fBmetadata profile config\fP -> \fBtag config\fP -> \fBlvmlocal.conf\fB -> \fBlvm.conf\fP - +.P +\fBdirect config override on command line\fP -> +\fBcommand profile config\fP -> +\fBmetadata profile config\fP -> +\fBtag config\fP -> +\fBlvmlocal.conf\fP -> +\fBlvm.conf\fP +.P No part of this cascade is compulsory. If there's no setting value found at the end of the cascade, a default value is used for that setting. Use \fBlvmconfig\fP to check what settings are in use and what the default values are. +. .SH SYNTAX -.LP +. This section describes the configuration file syntax. .LP Whitespace is not significant unless it is within quotes. @@ -109,15 +121,12 @@ They are treated as whitespace. Here is an informal grammar: .TP .BR file " = " value * -.br A configuration file consists of a set of values. .TP .BR value " = " section " | " assignment -.br A value can either be a new section, or an assignment. .TP .BR section " = " identifier " '" { "' " value "* '" } ' -.br A section groups associated values together. If the same section is encountered multiple times, the contents of all instances are concatenated together in the order of appearance. @@ -142,60 +151,58 @@ e.g. \fBlevel = 7\fP .br .TP .BR array " = '" [ "' ( " type " '" , "')* " type " '" ] "' | '" [ "' '" ] ' -.br Inhomogeneous arrays are supported. .br Elements must be separated by commas. .br An empty array is acceptable. .TP -.BR type " = " integer " | " float " | " string -.BR integer " = [0-9]*" +.BR type " = " integer | float | string +.BR integer " = [" 0 - 9 "]*" .br -.BR float " = [0-9]*'" . '[0-9]* +.BR float " = [" 0 - 9 "]*'" . "'[" 0 - 9 ]* .br -.B string \fR= '\fB"\fR'.*'\fB"\fR' +.BR string " = '" \(dq "' .* '" \(dq ' .IP Strings with spaces must be enclosed in double quotes, single words that start with a letter can be left unquoted. - +. .SH SETTINGS - +. The .B lvmconfig command prints the LVM configuration settings in various ways. See the man page .BR lvmconfig (8). - +.P Command to print a list of all possible config settings, with their default values: .br .B lvmconfig --type default - +.P Command to print a list of all possible config settings, with their default values, and a full description of each as a comment: .br .B lvmconfig --type default --withcomments - +.P Command to print a list of all possible config settings, with their current values (configured, non-default values are shown): .br .B lvmconfig --type current - +.P Command to print all config settings that have been configured with a different value than the default (configured, non-default values are shown): .br .B lvmconfig --type diff - +.P Command to print a single config setting, with its default value, and a full description, where "Section" refers to the config section, e.g. global, and "Setting" refers to the name of the specific setting, e.g. umask: .br .B lvmconfig --type default --withcomments Section/Setting - - +. .SH FILES .I #DEFAULT_SYS_DIR#/lvm.conf .br @@ -210,8 +217,8 @@ e.g. umask: .I #DEFAULT_LOCK_DIR# .br .I #DEFAULT_PROFILE_DIR# - +. .SH SEE ALSO -.BR lvm (8) +. +.BR lvm (8), .BR lvmconfig (8) - diff --git a/man/lvm2-activation-generator.8_main b/man/lvm2-activation-generator.8_main index 478c23bd5..4c54da285 100644 --- a/man/lvm2-activation-generator.8_main +++ b/man/lvm2-activation-generator.8_main @@ -1,49 +1,58 @@ .TH "LVM2-ACTIVATION-GENERATOR" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" +. .SH "NAME" +. lvm2-activation-generator - generator for systemd units to activate LVM volumes on boot +. .SH SYNOPSIS +. .B #SYSTEMD_GENERATOR_DIR#/lvm2-activation-generator -.sp +. .SH DESCRIPTION - +. The lvm2-activation-generator is called by \fBsystemd\fP(1) on boot to generate systemd units at runtime to activate LVM Logical Volumes (LVs) when global/event_activation=0 is set in \fBlvm.conf\fP(5). These units use \fBvgchange -aay\fP to activate LVs. - +.P If event_activation=1, the lvm2-activation-generator exits immediately without generating any systemd units, and LVM fully relies on event-based -activation to activate LVs. In this case, event-generated \fBpvscan ---cache -aay\fP commands activate LVs. - +activation to activate LVs. In this case, event-generated +.B pvscan --cache -aay +commands activate LVs. +.P These systemd units are generated by lvm2-activation-generator: -.sp -\fIlvm2-activation-early.service\fP +.P +.I lvm2-activation-early.service is run before systemd's special \fBcryptsetup.target\fP to activate LVs that are not layered on top of encrypted devices. - -\fIlvm2-activation.service\fP +.P +.I lvm2-activation.service is run after systemd's special \fBcryptsetup.target\fP to activate LVs that are layered on top of encrypted devices. - -\fIlvm2-activation-net.service\fP +.P +.I lvm2-activation-net.service is run after systemd's special \fBremote-fs-pre.target\fP to activate LVs that are layered on attached remote devices. - +.P Note that all the underlying LVM devices (Physical Volumes) need to be present when the service is run. If the there are any devices that appear to the system later, LVs using these devices need to be activated directly by \fBlvchange\fP(8) or \fBvgchange\fP(8). - +.P The lvm2-activation-generator implements the \fBGenerators Specification\fP as referenced in \fBsystemd\fP(1). -.sp +. .SH SEE ALSO -.BR lvm.conf (5) -.BR vgchange (8) -.BR lvchange (8) -.BR pvscan (8) +.nh +.ad l +.BR lvm.conf (5), +.BR vgchange (8), +.BR lvchange (8), +.BR pvscan (8), +.P +.BR systemd (1), +.BR systemd.target (5), +.BR systemd.special (7), +.P .BR udev (7) -.BR systemd (1) -.BR systemd.target (5) -.BR systemd.special (7) diff --git a/man/lvmcache.7_main b/man/lvmcache.7_main index 182dc0a79..20463a548 100644 --- a/man/lvmcache.7_main +++ b/man/lvmcache.7_main @@ -1,14 +1,16 @@ .TH "LVMCACHE" "7" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" +. .SH NAME +. lvmcache \(em LVM caching - +. .SH DESCRIPTION - +. \fBlvm\fP(8) includes two kinds of caching that can be used to improve the performance of a Logical Volume (LV). When caching, varying subsets of an LV's data are temporarily stored on a smaller, faster device (e.g. an SSD) to improve the performance of the LV. - +.P To do this with lvm, a new special LV is first created from the faster device. This LV will hold the cache. Then, the new fast LV is attached to the main LV by way of an lvconvert command. lvconvert inserts one of the @@ -17,164 +19,162 @@ mapper target combines the main LV and fast LV into a hybrid device that looks like the main LV, but has better performance. While the main LV is being used, portions of its data will be temporarily and transparently stored on the special fast LV. - +.P The two kinds of caching are: - +.P .IP \[bu] 2 A read and write hot-spot cache, using the dm-cache kernel module. This cache tracks access patterns and adjusts its content deliberately so that commonly used parts of the main LV are likely to be found on the fast storage. LVM refers to this using the LV type \fBcache\fP. - -.IP \[bu] 2 +. +.IP \[bu] A write cache, using the dm-writecache kernel module. This cache can be used with SSD or PMEM devices to speed up all writes to the main LV. Data read from the main LV is not stored in the cache, only newly written data. LVM refers to this using the LV type \fBwritecache\fP. - +. .SH USAGE - -.B 1. Identify main LV that needs caching - +. +.SS 1. Identify main LV that needs caching +. The main LV may already exist, and is located on larger, slower devices. A main LV would be created with a command like: - -.nf - $ lvcreate -n main -L Size vg /dev/slow_hhd -.fi - -.B 2. Identify fast LV to use as the cache - +.P +# lvcreate -n main -L Size vg /dev/slow_hhd +. +.SS 2. Identify fast LV to use as the cache +. A fast LV is created using one or more fast devices, like an SSD. This special LV will be used to hold the cache: - -.nf - $ lvcreate -n fast -L Size vg /dev/fast_ssd - - $ lvs -a +.P +# lvcreate -n fast -L Size vg /dev/fast_ssd +.P +# lvs -a LV Attr Type Devices fast -wi------- linear /dev/fast_ssd main -wi------- linear /dev/slow_hhd .fi - -.B 3. Start caching the main LV - +. +.SS 3. Start caching the main LV +. To start caching the main LV, convert the main LV to the desired caching type, and specify the fast LV to use as the cache: - -.nf +.P using dm-cache (with cachepool): - - $ lvconvert --type cache --cachepool fast vg/main - +.P +# lvconvert --type cache --cachepool fast vg/main +.P using dm-cache (with cachevol): - - $ lvconvert --type cache --cachevol fast vg/main - +.P +# lvconvert --type cache --cachevol fast vg/main +.P using dm-writecache (with cachevol): - - $ lvconvert --type writecache --cachevol fast vg/main - +.P +# lvconvert --type writecache --cachevol fast vg/main +.P For more alteratives see: +.br dm-cache command shortcut +.br dm-cache with separate data and metadata LVs -.fi - -.B 4. Display LVs - +. +.SS 4. Display LVs +. Once the fast LV has been attached to the main LV, lvm reports the main LV type as either \fBcache\fP or \fBwritecache\fP depending on the type used. While attached, the fast LV is hidden, and renamed with a _cvol or _cpool suffix. It is displayed by lvs -a. The _corig or _wcorig LV represents the original LV without the cache. - -.nf +.sp using dm-cache (with cachepool): - - $ lvs -ao+devices +.P +# lvs -ao+devices +.nf LV Pool Type Devices main [fast_cpool] cache main_corig(0) [fast_cpool] cache-pool fast_pool_cdata(0) [fast_cpool_cdata] linear /dev/fast_ssd [fast_cpool_cmeta] linear /dev/fast_ssd [main_corig] linear /dev/slow_hhd - +.fi +.sp using dm-cache (with cachevol): - - $ lvs -ao+devices +.P +# lvs -ao+devices +.P +.nf LV Pool Type Devices main [fast_cvol] cache main_corig(0) [fast_cvol] linear /dev/fast_ssd [main_corig] linear /dev/slow_hhd - +.fi +.sp using dm-writecache (with cachevol): - - $ lvs -ao+devices +.P +# lvs -ao+devices +.P +.nf LV Pool Type Devices main [fast_cvol] writecache main_wcorig(0) [fast_cvol] linear /dev/fast_ssd [main_wcorig] linear /dev/slow_hhd .fi - -.B 5. Use the main LV - +. +.SS 5. Use the main LV +. Use the LV until the cache is no longer wanted, or needs to be changed. - -.B 6. Stop caching - +. +.SS 6. Stop caching +. To stop caching the main LV and also remove unneeded cache pool, use the --uncache: - +.P +# lvconvert --uncache vg/main +.P +# lvs -a .nf - $ lvconvert --uncache vg/main - - $ lvs -a LV VG Attr Type Devices main vg -wi------- linear /dev/slow_hhd - +.fi +.P To stop caching the main LV, separate the fast LV from the main LV. This changes the type of the main LV back to what it was before the cache was attached. - +.P +# lvconvert --splitcache vg/main +.P +# lvs -a .nf - $ lvconvert --splitcache vg/main - - $ lvs -a LV VG Attr Type Devices fast vg -wi------- linear /dev/fast_ssd main vg -wi------- linear /dev/slow_hhd - .fi - -.SS Create a new LV with caching. - +. +.SS 7. Create a new LV with caching +. A new LV can be created with caching attached at the time of creation using the following command: - +.P .nf -$ lvcreate --type cache|writecache -n Name -L Size +# lvcreate --type cache|writecache -n Name -L Size --cachedevice /dev/fast_ssd vg /dev/slow_hhd .fi - +.P The main LV is created with the specified Name and Size from the slow_hhd. A hidden fast LV is created on the fast_ssd and is then attached to the new main LV. If the fast_ssd is unused, the entire disk will be used as the cache unless the --cachesize option is used to specify a size for the fast LV. The --cachedevice option can be repeated to use multiple disks for the fast LV. - +. .SH OPTIONS - -\& - +. .SS option args - -\& - +. .B --cachepool .IR CachePoolLV | LV -.br - +.P Pass this option a cachepool LV or a standard LV. When using a cache pool, lvm places cache data and cache metadata on different LVs. The two LVs together are called a cache pool. This has a bit better performance @@ -184,19 +184,17 @@ A cache pool is represented as a special type of LV that cannot be used directly. If a standard LV is passed with this option, lvm will first convert it to a cache pool by combining it with another LV to use for metadata. This option can be used with dm-cache. - +.P .B --cachevol .I LV -.br - +.P Pass this option a fast LV that should be used to hold the cache. With a cachevol, cache data and metadata are stored in different parts of the same fast LV. This option can be used with dm-writecache or dm-cache. - +.P .B --cachedevice .I PV -.br - +.P This option can be used in place of --cachevol, in which case a cachevol LV will be created using the specified device. This option can be repeated to create a cachevol using multiple devices, or a tag name can be @@ -204,112 +202,96 @@ specified in which case the cachevol will be created using any of the devices with the given tag. If a named cache device is unused, the entire device will be used to create the cachevol. To create a cachevol of a specific size from the cache devices, include the --cachesize option. - -\& - +. .SS dm-cache block size - -\& - +. A cache pool will have a logical block size of 4096 bytes if it is created on a device with a logical block size of 4096 bytes. - +.P If a main LV has logical block size 512 (with an existing xfs file system using that size), then it cannot use a cache pool with a 4096 logical block size. If the cache pool is attached, the main LV will likely fail to mount. - +.P To avoid this problem, use a mkfs option to specify a 4096 block size for the file system, or attach the cache pool before running mkfs. - +. .SS dm-writecache block size - -\& - +. The dm-writecache block size can be 4096 bytes (the default), or 512 bytes. The default 4096 has better performance and should be used except when 512 is necessary for compatibility. The dm-writecache block size is specified with --cachesettings block_size=4096|512 when caching is started. - +.P When a file system like xfs already exists on the main LV prior to caching, and the file system is using a block size of 512, then the writecache block size should be set to 512. (The file system will likely fail to mount if writecache block size of 4096 is used in this case.) - +.P Check the xfs sector size while the fs is mounted: - +.P +# xfs_info /dev/vg/main .nf -$ xfs_info /dev/vg/main Look for sectsz=512 or sectsz=4096 .fi - +.P The writecache block size should be chosen to match the xfs sectsz value. - +.P It is also possible to specify a sector size of 4096 to mkfs.xfs when creating the file system. In this case the writecache block size of 4096 can be used. - +. .SS dm-writecache settings - -\& - +. Tunable parameters can be passed to the dm-writecache kernel module using the --cachesettings option when caching is started, e.g. - +.P .nf -$ lvconvert --type writecache --cachevol fast \\ +# lvconvert --type writecache --cachevol fast \\ --cachesettings 'high_watermark=N writeback_jobs=N' vg/main .fi - +.P Tunable options are: - -.IP \[bu] 2 +. +.TP high_watermark = <percent> - Start writeback when the writecache usage reaches this percent (0-100). - -.IP \[bu] 2 +. +.TP low_watermark = <percent> - Stop writeback when the writecache usage reaches this percent (0-100). - -.IP \[bu] 2 +. +.TP writeback_jobs = <count> - 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. - -.IP \[bu] 2 +. +.TP autocommit_blocks = <count> - When the application writes this amount of blocks without issuing the FLUSH request, the blocks are automatically commited. - -.IP \[bu] 2 +. +.TP autocommit_time = <milliseconds> - The data is automatically commited if this time passes and no FLUSH request is received. - -.IP \[bu] 2 +. +.TP fua = 0|1 - Use the FUA flag when writing data from persistent memory back to the underlying device. Applicable only to persistent memory. - -.IP \[bu] 2 +. +.TP nofua = 0|1 - 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. Testing is necessary to determine which. Applicable only to persistent memory. - -.IP \[bu] 2 +. +.TP cleaner = 0|1 - Setting cleaner=1 enables the writecache cleaner mode in which data is gradually flushed from the cache. If this is done prior to detaching the writecache, then the splitcache command will have little or no flushing to @@ -317,99 +299,88 @@ perform. If not done beforehand, the splitcache command enables the cleaner mode and waits for flushing to complete before detaching the writecache. Adding cleaner=0 to the splitcache command will skip the cleaner mode, and any required flushing is performed in device suspend. - +. .SS dm-cache with separate data and metadata LVs - -\& - +. Preferred way of using dm-cache is to place the cache metadata and cache data on separate LVs. To do this, a "cache pool" is created, which is a special LV that references two sub LVs, one for data and one for metadata. - +.P To create a cache pool of given data size and let lvm2 calculate appropriate metadata size: - -.nf -$ lvcreate --type cache-pool -L DataSize -n fast vg /dev/fast_ssd1 -.fi - +.P +# lvcreate --type cache-pool -L DataSize -n fast vg /dev/fast_ssd1 +.P To create a cache pool from separate LV and let lvm2 calculate appropriate cache metadata size: - -.nf -$ lvcreate -n fast -L DataSize vg /dev/fast_ssd1 -$ lvconvert --type cache-pool vg/fast /dev/fast_ssd1 -.fi - +.P +# lvcreate -n fast -L DataSize vg /dev/fast_ssd1 +.br +# lvconvert --type cache-pool vg/fast /dev/fast_ssd1 +.br +.P To create a cache pool from two separate LVs: - -.nf -$ lvcreate -n fast -L DataSize vg /dev/fast_ssd1 -$ lvcreate -n fastmeta -L MetadataSize vg /dev/fast_ssd2 -$ lvconvert --type cache-pool --poolmetadata fastmeta vg/fast -.fi - +.P +# lvcreate -n fast -L DataSize vg /dev/fast_ssd1 +.br +# lvcreate -n fastmeta -L MetadataSize vg /dev/fast_ssd2 +.br +# lvconvert --type cache-pool --poolmetadata fastmeta vg/fast +.P Then use the cache pool LV to start caching the main LV: - -.nf -$ lvconvert --type cache --cachepool fast vg/main -.fi - +.P +# lvconvert --type cache --cachepool fast vg/main +.P A variation of the same procedure automatically creates a cache pool when caching is started. To do this, use a standard LV as the --cachepool (this will hold cache data), and use another standard LV as the --poolmetadata (this will hold cache metadata). LVM will create a cache pool LV from the two specified LVs, and use the cache pool to start caching the main LV. - +.P .nf -$ lvcreate -n fast -L DataSize vg /dev/fast_ssd1 -$ lvcreate -n fastmeta -L MetadataSize vg /dev/fast_ssd2 -$ lvconvert --type cache --cachepool fast --poolmetadata fastmeta vg/main +# lvcreate -n fast -L DataSize vg /dev/fast_ssd1 +# lvcreate -n fastmeta -L MetadataSize vg /dev/fast_ssd2 +# lvconvert --type cache --cachepool fast --poolmetadata fastmeta vg/main .fi - +. .SS dm-cache cache modes - -\& - +. The default dm-cache cache mode is "writethrough". Writethrough ensures that any data written will be stored both in the cache and on the origin LV. The loss of a device associated with the cache in this case would not mean the loss of any data. - +.P A second cache mode is "writeback". Writeback delays writing data blocks from the cache back to the origin LV. This mode will increase performance, but the loss of a cache device can result in lost data. - +.P With the --cachemode option, the cache mode can be set when caching is started, or changed on an LV that is already cached. The current cache mode can be displayed with the cache_mode reporting option: - +.P .B lvs -o+cache_mode VG/LV - +.P .BR lvm.conf (5) .B allocation/cache_mode .br defines the default cache mode. - +.P .nf -$ lvconvert --type cache --cachemode writethrough \\ +# lvconvert --type cache --cachemode writethrough \\ --cachepool fast vg/main - - -$ lvconvert --type cache --cachemode writethrough \\ +.P +# lvconvert --type cache --cachemode writethrough \\ --cachevol fast vg/main .nf - +. .SS dm-cache chunk size - -\& - +. The size of data blocks managed by dm-cache can be specified with the --chunksize option when caching is started. The default unit is KiB. The value must be a multiple of 32KiB between 32KiB and 1GiB. Cache chunks bigger then 512KiB shall be only used when necessary. - +.P Using a chunk size that is too large can result in wasteful use of the cache, in which small reads and writes cause large sections of an LV to be stored in the cache. It can also require increasing migration threshold @@ -420,100 +391,90 @@ cache origin LV. However, choosing a chunk size that is too small can result in more overhead trying to manage the numerous chunks that become mapped into the cache. Overhead can include both excessive CPU time searching for chunks, and excessive memory tracking chunks. - +.P Command to display the chunk size: -.br +.P .B lvs -o+chunksize VG/LV - +.P .BR lvm.conf (5) .B cache_pool_chunk_size -.br +.P controls the default chunk size. - +.P The default value is shown by: -.br +.P .B lvmconfig --type default allocation/cache_pool_chunk_size - +.P Checking migration threshold (in sectors) of running cached LV: .br .B lvs -o+kernel_cache_settings VG/LV - - +. .SS dm-cache migration threshold - -\& - +. Migrating data between the origin and cache LV uses bandwidth. The user can set a throttle to prevent more than a certain amount of migration occurring at any one time. Currently dm-cache is not taking any account of normal io traffic going to the devices. - +.P User can set migration threshold via cache policy settings as "migration_threshold=<#sectors>" to set the maximum number of sectors being migrated, the default being 2048 sectors (1MiB). - +.P Command to set migration threshold to 2MiB (4096 sectors): -.br +.P .B lvcreate --cachepolicy 'migration_threshold=4096' VG/LV - - +.P Command to display the migration threshold: -.br +.P .B lvs -o+kernel_cache_settings,cache_settings VG/LV .br .B lvs -o+chunksize VG/LV - - +. .SS dm-cache cache policy - -\& - +. The dm-cache subsystem has additional per-LV parameters: the cache policy to use, and possibly tunable parameters for the cache policy. Three policies are currently available: "smq" is the default policy, "mq" is an older implementation, and "cleaner" is used to force the cache to write back (flush) all cached writes to the origin LV. - +.P The older "mq" policy has a number of tunable parameters. The defaults are chosen to be suitable for the majority of systems, but in special circumstances, changing the settings can improve performance. - +.P With the --cachepolicy and --cachesettings options, the cache policy and settings can be set when caching is started, or changed on an existing cached LV (both options can be used together). The current cache policy and settings can be displayed with the cache_policy and cache_settings reporting options: - +.P .B lvs -o+cache_policy,cache_settings VG/LV - -.nf +.P Change the cache policy and settings of an existing LV. - -$ lvchange --cachepolicy mq --cachesettings \\ +.nf +# lvchange --cachepolicy mq --cachesettings \\ \(aqmigration_threshold=2048 random_threshold=4\(aq vg/main .fi - +.P .BR lvm.conf (5) .B allocation/cache_policy .br defines the default cache policy. - +.P .BR lvm.conf (5) .B allocation/cache_settings .br defines the default cache settings. - +. .SS dm-cache using metadata profiles - -\& - +. Cache pools allows to set a variety of options. Lots of these settings can be specified in lvm.conf or profile settings. You can prepare a number of different profiles in the #DEFAULT_SYS_DIR#/profile directory and just specify the metadata profile file name when caching LV or creating cache-pool. Check the output of \fBlvmconfig --type default --withcomments\fP for a detailed description of all individual cache settings. - +.P .I Example .nf # cat <<EOF > #DEFAULT_SYS_DIR#/profile/cache_big_chunk.profile @@ -531,80 +492,74 @@ allocation { } } EOF - +.P # lvcreate --cache -L10G --metadataprofile cache_big_chunk vg/main /dev/fast_ssd # lvcreate --cache -L10G --config 'allocation/cache_pool_chunk_size=512' vg/main /dev/fast_ssd .fi - +. .SS dm-cache spare metadata LV - -\& - +. See .BR lvmthin (7) for a description of the "pool metadata spare" LV. The same concept is used for cache pools. - +. .SS dm-cache metadata formats - -\& - +. There are two disk formats for dm-cache metadata. The metadata format can be specified with --cachemetadataformat when caching is started, and cannot be changed. Format \fB2\fP has better performance; it is more compact, and stores dirty bits in a separate btree, which improves the speed of shutting down the cache. With \fBauto\fP, lvm selects the best option provided by the current dm-cache kernel module. - +. .SS RAID1 cache device - -\& - +. RAID1 can be used to create the fast LV holding the cache so that it can tolerate a device failure. (When using dm-cache with separate data and metadata LVs, each of the sub-LVs can use RAID1.) - +.P .nf -$ lvcreate -n main -L Size vg /dev/slow -$ lvcreate --type raid1 -m 1 -n fast -L Size vg /dev/ssd1 /dev/ssd2 -$ lvconvert --type cache --cachevol fast vg/main +# lvcreate -n main -L Size vg /dev/slow +# lvcreate --type raid1 -m 1 -n fast -L Size vg /dev/ssd1 /dev/ssd2 +# lvconvert --type cache --cachevol fast vg/main .fi - +. .SS dm-cache command shortcut - -\& - +. A single command can be used to cache main LV with automatic creation of a cache-pool: - +.P .nf -$ lvcreate --cache --size CacheDataSize VG/LV [FastPVs] +# lvcreate --cache --size CacheDataSize VG/LV [FastPVs] .fi - +.P or the longer variant - +.P .nf -$ lvcreate --type cache --size CacheDataSize \\ +# lvcreate --type cache --size CacheDataSize \\ --name NameCachePool VG/LV [FastPVs] .fi - +.P In this command, the specified LV already exists, and is the main LV to be cached. The command creates a new cache pool with size and given name or the name is automatically selected from a sequence lvolX_cpool, using the optionally specified fast PV(s) (typically an ssd). Then it attaches the new cache pool to the existing main LV to begin caching. - +.P (Note: ensure that the specified main LV is a standard LV. If a cache pool LV is mistakenly specified, then the command does something different.) - +.P (Note: the type option is interpreted differently by this command than by normal lvcreate commands in which --type specifies the type of the newly created LV. In this case, an LV with type cache-pool is being created, and the existing main LV is being converted to type cache.) - - +. .SH SEE ALSO +. +.nh +.ad l .BR lvm.conf (5), .BR lvchange (8), .BR lvcreate (8), @@ -614,7 +569,12 @@ and the existing main LV is being converted to type cache.) .BR lvrename (8), .BR lvresize (8), .BR lvs (8), +.br .BR vgchange (8), .BR vgmerge (8), .BR vgreduce (8), -.BR vgsplit (8) +.BR vgsplit (8), +.P +.BR cache_dump (8), +.BR cache_check (8), +.BR cache_repair (8) diff --git a/man/lvmdbusd.8_main b/man/lvmdbusd.8_main index 99a7001f1..3990a024f 100644 --- a/man/lvmdbusd.8_main +++ b/man/lvmdbusd.8_main @@ -8,31 +8,28 @@ lvmdbusd \(em LVM D-Bus daemon . .ad l .B lvmdbusd -.RB [ --debug \] -.RB [ --udev \] +.RB [ --debug ] +.RB [ --udev ] .ad b . .SH DESCRIPTION . lvmdbusd is a service which provides a D-Bus API to the logical volume manager (LVM). -Run +Run .BR lvmdbusd (8) as root. . .SH OPTIONS . -.HP -.BR --debug -.br -Enable debug statements +.TP 8 +.B --debug +Enable debug statements . -.HP -.BR --udev -.br +.TP +.B --udev Use udev events to trigger updates . .SH SEE ALSO . -.nh .BR dbus-send (1), .BR lvm (8) diff --git a/man/lvmdump.8_main b/man/lvmdump.8_main index cbd5f15ef..1fa6d817d 100644 --- a/man/lvmdump.8_main +++ b/man/lvmdump.8_main @@ -1,7 +1,11 @@ .TH LVMDUMP 8 "LVM TOOLS #VERSION#" "Red Hat, Inc." +. .SH NAME +. lvmdump \(em create lvm2 information dumps for diagnostic purposes +. .SH SYNOPSIS +. .B lvmdump .RB [ -a ] .RB [ -c ] @@ -13,46 +17,54 @@ lvmdump \(em create lvm2 information dumps for diagnostic purposes .RB [ -p ] .RB [ -s ] .RB [ -u ] +. .SH DESCRIPTION +. lvmdump is a tool to dump various information concerning LVM2. By default, it creates a tarball suitable for submission along with a problem report. -.PP +.P The content of the tarball is as follows: -.br -- dmsetup info -.br -- table of currently running processes -.br -- recent entries from /var/log/messages (containing system messages) -.br -- complete lvm configuration and cache (content of #DEFAULT_SYS_DIR#) -.br -- list of device nodes present under /dev -.br -- list of files present /sys/block -.br -- list of files present /sys/devices/virtual/block -.br -- if enabled with -m, metadata dump will be also included -.br -- if enabled with -a, debug output of vgscan, pvscan and list of all available volume groups, physical volumes and logical volumes will be included -.br -- if enabled with -l, lvmetad state if running -.br -- if enabled with -p, lvmpolld state if running -.br -- if enabled with -s, system info and context -.br -- if enabled with -u, udev info and context +.ad l +.PD 0 +.IP \[bu] 2 +dmsetup info +.IP \[bu] +table of currently running processes +.IP \[bu] +recent entries from /var/log/messages (containing system messages) +.IP \[bu] +complete lvm configuration and cache (content of #DEFAULT_SYS_DIR#) +.IP \[bu] +list of device nodes present under /dev +.IP \[bu] +list of files present /sys/block +.IP \[bu] +list of files present /sys/devices/virtual/block +.IP \[bu] +if enabled with -m, metadata dump will be also included +.IP \[bu] +if enabled with -a, debug output of vgscan, pvscan and list of all available volume groups, physical volumes and logical volumes will be included +.IP \[bu] +if enabled with -l, lvmetad state if running +.IP \[bu] +if enabled with -p, lvmpolld state if running +.IP \[bu] +if enabled with -s, system info and context +.IP \[bu] +if enabled with -u, udev info and context +.PD +.ad b +. .SH OPTIONS +. .TP .B -a Advanced collection. \fBWARNING\fR: if lvm is already hung, then this script may hang as well if \fB-a\fR is used. .TP -.B -d \fIdirectory +.B -d \fIdirectory Dump into a directory instead of tarball By default, lvmdump will produce a single compressed tarball containing all the information. Using this option, it can be instructed to only @@ -92,16 +104,19 @@ Gather udev info and context: /etc/udev/udev.conf file, udev daemon version (content of /lib/udev/rules.d and /etc/udev/rules.d directory), list of files in /lib/udev directory and dump of current udev database content (the output of 'udevadm info --export-db' command). +. .SH ENVIRONMENT VARIABLES +. .TP -\fBLVM_BINARY\fP +.B LVM_BINARY The LVM2 binary to use. Defaults to "lvm". -Sometimes you might need to set this to "#LVM_PATH#/lvm.static", for example. +Sometimes you might need to set this to "#LVM_PATH#.static", for example. .TP -\fBDMSETUP_BINARY\fP +.B DMSETUP_BINARY The dmsetup binary to use. Defaults to "dmsetup". -.PP +. .SH SEE ALSO +. .BR lvm (8) diff --git a/man/lvmlockctl.8_main b/man/lvmlockctl.8_main index 14ce926b5..8b7b00977 100644 --- a/man/lvmlockctl.8_main +++ b/man/lvmlockctl.8_main @@ -1,69 +1,79 @@ .TH "LVMLOCKCTL" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" - +. .SH NAME -lvmlockctl \(em Control for lvmlockd - +. +lvmlockctl \(em Control for lvmlockd +. +.SH SYNOPSIS +. +.BR lvmlockctl " [" \fIoptions ] +. .SH DESCRIPTION +. This command interacts with .BR lvmlockd (8). - +. .SH OPTIONS - -lvmlockctl [options] - -.B --help | -h - Show this help information. - -.B --quit | -q - Tell lvmlockd to quit. - -.B --info | -i - Print lock state information from lvmlockd. - -.B --dump | -d - Print log buffer from lvmlockd. - -.B --wait | -w 0|1 - Wait option for other commands. - -.B --force | -f 0|1 - Force option for other commands. - -.B --kill | -k -.I vgname - Kill access to the VG when sanlock cannot renew lease. - -.B --drop | -r -.I vgname - Clear locks for the VG when it is unused after kill (-k). - -.B --gl-enable | -E -.I vgname - Tell lvmlockd to enable the global lock in a sanlock VG. - -.B --gl-disable | -D -.I vgname - Tell lvmlockd to disable the global lock in a sanlock VG. - -.B --stop-lockspaces | -S - Stop all lockspaces. - - +. +.TP +.BR -h | --help +Show this help information. +. +.TP +.BR -q | --quit +Tell lvmlockd to quit. +. +.TP +.BR -i | --info +Print lock state information from lvmlockd. +. +.TP +.BR -d | --dump +Print log buffer from lvmlockd. +. +.TP +.BR -w | --wait\ 0 | 1 +Wait option for other commands. +. +.TP +.BR -f | --force\ 0 | 1 +Force option for other commands. +. +.TP +.BR -k | --kill " " \fIvgname +Kill access to the VG when sanlock cannot renew lease. +. +.TP +.BR -r | --drop " " \fIvgname +Clear locks for the VG when it is unused after kill (-k). +. +.TP +.BR -E | --gl-enable " " \fIvgname +Tell lvmlockd to enable the global lock in a sanlock VG. +. +.TP +.BR -D | --gl-disable " " \fIvgname +Tell lvmlockd to disable the global lock in a sanlock VG. +. +.TP +.BR -S | --stop-lockspaces +Stop all lockspaces. +. .SH USAGE - +. .SS info - +. This collects and displays lock state from lvmlockd. The display is primitive, incomplete and will change in future version. To print the raw lock state from lvmlockd, combine this option with --dump|-d. - +. .SS dump - +. This collects the circular log buffer of debug statements from lvmlockd and prints it. - +. .SS kill - +. This is run by sanlock when it loses access to the storage holding leases for a VG. It runs the command specified in lvm.conf lvmlockctl_kill_command to deactivate LVs in the VG. If the specified @@ -73,34 +83,37 @@ is specified, or the command fails, then the user must intervene to forcefully deactivate LVs in the VG, and if successful, run lvmlockctl --drop. For more, see .BR lvmlockd (8). - +. .SS drop - +. This should only be run after a VG has been successfully deactivated following an lvmlockctl --kill command. It clears the stale lockspace from lvmlockd. When lvmlockctl_kill_command is used, the --kill command may run drop automatically. For more, see .BR lvmlockd (8). - +. .SS gl-enable - +. This enables the global lock in a sanlock VG. This is necessary if the VG that previously held the global lock is removed. For more, see .BR lvmlockd (8). - +. .SS gl-disable - +. This disables the global lock in a sanlock VG. This is necessary if the global lock has mistakenly been enabled in more than one VG. The global lock should be disabled in all but one sanlock VG. For more, see .BR lvmlockd (8). - +. .SS stop-lockspaces - +. This tells lvmlockd to stop all lockspaces. It can be useful to stop lockspaces for VGs that the vgchange --lock-stop comand can no longer see, or to stop the dlm global lockspace which is not directly stopped by the vgchange command. The wait and force options can be used with this command. - - +. +.SH SEE ALSO +. +.BR lvm (8), +.BR lvmlockd (8) diff --git a/man/lvmlockd.8_main b/man/lvmlockd.8_main index d1eee63fc..717292dc6 100644 --- a/man/lvmlockd.8_main +++ b/man/lvmlockd.8_main @@ -1,13 +1,19 @@ .TH "LVMLOCKD" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" - +. .SH NAME +. lvmlockd \(em LVM locking daemon - +. +.SH SYNOPSIS +. +.BR lvmlockd " [" \fIoptions ] +. .SH DESCRIPTION +. LVM commands use lvmlockd to coordinate access to shared storage. .br When LVM is used on devices shared by multiple hosts, locks will: - +.br \[bu] coordinate reading and writing of LVM metadata .br @@ -17,116 +23,119 @@ validate caching of LVM metadata \[bu] prevent conflicting activation of logical volumes .br - lvmlockd uses an external lock manager to perform basic locking. -.br +.P Lock manager (lock type) options are: - +.br \[bu] sanlock: places locks on disk within LVM storage. .br \[bu] dlm: uses network communication and a cluster manager. .br - +. .SH OPTIONS - -lvmlockd [options] - -For default settings, see lvmlockd -h. - -.B --help | -h - Show this help information. - -.B --version | -V - Show version of lvmlockd. - -.B --test | -T - Test mode, do not call lock manager. - -.B --foreground | -f - Don't fork. - -.B --daemon-debug | -D - Don't fork and print debugging to stdout. - -.B --pid-file | -p -.I path - Set path to the pid file. - -.B --socket-path | -s -.I path - Set path to the socket to listen on. - -.B --adopt-file -.I path - Set path to the adopt file. - -.B --syslog-priority | -S err|warning|debug - Write log messages from this level up to syslog. - -.B --gl-type | -g sanlock|dlm - Set global lock type to be sanlock or dlm. - -.B --host-id | -i -.I num - Set the local sanlock host id. - -.B --host-id-file | -F -.I path - A file containing the local sanlock host_id. - -.B --sanlock-timeout | -o -.I seconds - Override the default sanlock I/O timeout. - -.B --adopt | -A 0|1 - Enable (1) or disable (0) lock adoption. - +. +.TP +.BR -h | --help +Show this help information. +. +.TP +.BR -V | --version +Show version of lvmlockd. +. +.TP +.BR -T | --test +Test mode, do not call lock manager. +. +.TP +.BR -f | --foreground +Don't fork. +. +.TP +.BR -D | --daemon-debug +Don't fork and print debugging to stdout. +. +.TP +.BR -p | --pid-file " " \fIpath +Set path to the pid file. +. +.TP +.BR -s | --socket-path " " \fIpath +Set path to the socket to listen on. +. +.TP +.B --adopt-file \fIpath +Set path to the adopt file. +. +.TP +.BR -S | --syslog-priority " " err | warning | debug +Write log messages from this level up to syslog. +. +.TP +.BR -g | --gl-type " " sanlock | dlm +Set global lock type to be sanlock or dlm. +. +.TP +.BR -i | --host-id " " \fInum +Set the local sanlock host id. +. +.TP +.BR -F | --host-id-file " " \fIpath +A file containing the local sanlock host_id. +. +.TP +.BR -o | --sanlock-timeout " " \fIseconds +Override the default sanlock I/O timeout. +. +.TP +.BR -A | --adopt " " 0 | 1 +Enable (1) or disable (0) lock adoption. +. .SH USAGE - +. .SS Initial set up - +. Setting up LVM to use lvmlockd and a shared VG for the first time includes some one time set up steps: - +. .SS 1. choose a lock manager - +. .I dlm .br If dlm (or corosync) are already being used by other cluster software, then select dlm. dlm uses corosync which requires additional configuration beyond the scope of this document. See corosync and dlm documentation for instructions on configuration, set up and usage. - +.P .I sanlock .br Choose sanlock if dlm/corosync are not otherwise required. sanlock does not depend on any clustering software or configuration. - +. .SS 2. configure hosts to use lvmlockd - +. On all hosts running lvmlockd, configure lvm.conf: .nf use_lvmlockd = 1 .fi - +.P .I sanlock .br Assign each host a unique host_id in the range 1-2000 by setting .br #DEFAULT_SYS_DIR#/lvmlocal.conf local/host_id - +. .SS 3. start lvmlockd - +. Start the lvmlockd daemon. .br Use systemctl, a cluster resource agent, or run directly, e.g. .br systemctl start lvmlockd - +. .SS 4. start lock manager - +. .I sanlock .br Start the sanlock and wdmd daemons. @@ -134,7 +143,7 @@ Start the sanlock and wdmd daemons. Use systemctl or run directly, e.g. .br systemctl start wdmd sanlock - +.P .I dlm .br Start the dlm and corosync daemons. @@ -142,42 +151,41 @@ Start the dlm and corosync daemons. Use systemctl, a cluster resource agent, or run directly, e.g. .br systemctl start corosync dlm - +. .SS 5. create VG on shared devices - +. vgcreate --shared <vgname> <devices> - +.P The shared option sets the VG lock type to sanlock or dlm depending on which lock manager is running. LVM commands acquire locks from lvmlockd, and lvmlockd uses the chosen lock manager. - +. .SS 6. start VG on all hosts - +. vgchange --lock-start - +.P Shared VGs must be started before they are used. Starting the VG performs lock manager initialization that is necessary to begin using locks (i.e. creating and joining a lockspace). Starting the VG may take some time, and until the start completes the VG may not be modified or activated. - +. .SS 7. create and activate LVs - +. Standard lvcreate and lvchange commands are used to create and activate LVs in a shared VG. - +.P An LV activated exclusively on one host cannot be activated on another. When multiple hosts need to use the same LV concurrently, the LV can be activated with a shared lock (see lvchange options -aey vs -asy.) (Shared locks are disallowed for certain LV types that cannot be used from multiple hosts.) - - +. .SS Normal start up and shut down - +. After initial set up, start up and shut down include the following steps. They can be performed directly or may be automated using systemd or a cluster resource manager/agents. - +.P \[bu] start lvmlockd .br @@ -190,9 +198,9 @@ vgchange --lock-start \[bu] activate LVs in shared VGs .br - +.P The shut down sequence is the reverse: - +.P \[bu] deactivate LVs in shared VGs .br @@ -204,35 +212,32 @@ stop lock manager .br \[bu] stop lvmlockd -.br - -.P - +. .SH TOPICS - +. .SS Protecting VGs on shared devices - +. The following terms are used to describe the different ways of accessing VGs on shared devices. - +.P .I "shared VG" - +.P A shared VG exists on shared storage that is visible to multiple hosts. LVM acquires locks through lvmlockd to coordinate access to shared VGs. A shared VG has lock_type "dlm" or "sanlock", which specifies the lock manager lvmlockd will use. - +.P When the lock manager for the lock type is not available (e.g. not started or failed), lvmlockd is unable to acquire locks for LVM commands. In this situation, LVM commands are only allowed to read and display the VG; changes and activation will fail. - +.P .I "local VG" - +.P A local VG is meant to be used by a single host. It has no lock type or lock type "none". A local VG typically exists on local (non-shared) devices and cannot be used concurrently from different hosts. - +.P If a local VG does exist on shared devices, it should be owned by a single host by having the system ID set, see .BR lvmsystemid (7). @@ -241,97 +246,92 @@ will ignore it. A VG with no lock type and no system ID should be excluded from all but one host using lvm.conf filters. Without any of these protections, a local VG on shared devices can be easily damaged or destroyed. - +.P .I "clvm VG" - +.P A clvm VG (or clustered VG) is a VG on shared storage (like a shared VG) that requires clvmd for clustering and locking. See below for converting a clvm/clustered VG to a shared VG. - - -.SS shared VGs from hosts not using lvmlockd - +. +.SS Shared VGs from hosts not using lvmlockd +. Hosts that do not use shared VGs will not be running lvmlockd. In this case, shared VGs that are still visible to the host will be ignored -(like foreign VGs, see -.BR lvmsystemid (7).) - +(like foreign VGs, see +.BR lvmsystemid (7)). +.P The --shared option for reporting and display commands causes shared VGs to be displayed on a host not using lvmlockd, like the --foreign option does for foreign VGs. - - -.SS creating the first sanlock VG - +. +.SS Creating the first sanlock VG +. When use_lvmlockd is first enabled in lvm.conf, and before the first sanlock VG is created, no global lock will exist. In this initial state, LVM commands try and fail to acquire the global lock, producing a warning, and some commands are disallowed. Once the first sanlock VG is created, the global lock will be available, and LVM will be fully operational. - +.P When a new sanlock VG is created, its lockspace is automatically started on the host that creates it. Other hosts need to run 'vgchange --lock-start' to start the new VG before they can use it. - +.P Creating the first sanlock VG is not protected by locking, so it requires special attention. This is because sanlock locks exist on storage within the VG, so they are not available until after the VG is created. The first sanlock VG that is created will automatically contain the "global lock". Be aware of the following special considerations: - +.P .IP \[bu] 2 The first vgcreate command needs to be given the path to a device that has not yet been initialized with pvcreate. The pvcreate initialization will be done by vgcreate. This is because the pvcreate command requires the global lock, which will not be available until after the first sanlock VG is created. - -.IP \[bu] 2 +.IP \[bu] Because the first sanlock VG will contain the global lock, this VG needs to be accessible to all hosts that will use sanlock shared VGs. All hosts will need to use the global lock from the first sanlock VG. - -.IP \[bu] 2 +.IP \[bu] The device and VG name used by the initial vgcreate will not be protected from concurrent use by another vgcreate on another host. - +.P See below for more information about managing the sanlock global lock. - - -.SS using shared VGs - +. +.SS Using shared VGs +. In the 'vgs' command, shared VGs are indicated by "s" (for shared) in the sixth attr field, and by "shared" in the "--options shared" report field. The specific lock type and lock args for a shared VG can be displayed with 'vgs -o+locktype,lockargs'. - +.P Shared VGs need to be "started" and "stopped", unlike other types of VGs. See the following section for a full description of starting and stopping. - +.P Removing a shared VG will fail if other hosts have the VG started. Run vgchange --lock-stop <vgname> on all other hosts before vgremove. (It may take several seconds before vgremove recognizes that all hosts have stopped a sanlock VG.) - -.SS starting and stopping VGs - +. +.SS Starting and stopping VGs +. Starting a shared VG (vgchange --lock-start) causes the lock manager to start (join) the lockspace for the VG on the host where it is run. This makes locks for the VG available to LVM commands on the host. Before a VG is started, only LVM commands that read/display the VG are allowed to continue without locks (and with a warning). - +.P Stopping a shared VG (vgchange --lock-stop) causes the lock manager to stop (leave) the lockspace for the VG on the host where it is run. This makes locks for the VG inaccessible to the host. A VG cannot be stopped while it has active LVs. - +.P When using the lock type sanlock, starting a VG can take a long time (potentially minutes if the host was previously shut down without cleanly stopping the VG.) - +.P A shared VG can be started after all the following are true: -.br +.P \[bu] lvmlockd is running .br @@ -340,55 +340,52 @@ the lock manager is running .br \[bu] the VG's devices are visible on the system -.br - +.P A shared VG can be stopped if all LVs are deactivated. - +.P All shared VGs can be started/stopped using: .br vgchange --lock-start .br vgchange --lock-stop - - +.P Individual VGs can be started/stopped using: .br vgchange --lock-start <vgname> ... .br vgchange --lock-stop <vgname> ... - +.P To make vgchange not wait for start to complete: .br vgchange --lock-start --lock-opt nowait ... - +.P lvmlockd can be asked directly to stop all lockspaces: .br lvmlockctl -S|--stop-lockspaces - +.P To start only selected shared VGs, use the lvm.conf activation/lock_start_list. When defined, only VG names in this list are started by vgchange. If the list is not defined (the default), all visible shared VGs are started. To start only "vg1", use the following lvm.conf configuration: - +.P .nf activation { lock_start_list = [ "vg1" ] ... } .fi - - -.SS internal command locking - +. +.SS Internal command locking +. To optimize the use of LVM with lvmlockd, be aware of the three kinds of locks and when they are used: - +.P .I Global lock - +.P The global lock is associated with global information, which is information not isolated to a single VG. This includes: - +.P \[bu] The global VG namespace. .br @@ -397,40 +394,39 @@ The set of orphan PVs and unused devices. .br \[bu] The properties of orphan PVs, e.g. PV size. -.br - +.P The global lock is acquired in shared mode by commands that read this information, or in exclusive mode by commands that change it. For example, the command 'vgs' acquires the global lock in shared mode because it reports the list of all VG names, and the vgcreate command acquires the global lock in exclusive mode because it creates a new VG name, and it takes a PV from the list of unused PVs. - +.P When an LVM command is given a tag argument, or uses select, it must read all VGs to match the tag or selection, which causes the global lock to be acquired. - +.P .I VG lock - +.P A VG lock is associated with each shared VG. The VG lock is acquired in shared mode to read the VG and in exclusive mode to change the VG or activate LVs. This lock serializes access to a VG with all other LVM commands accessing the VG from all hosts. - +.P The command 'vgs <vgname>' does not acquire the global lock (it does not need the list of all VG names), but will acquire the VG lock on each VG name argument. - +.P .I LV lock - +.P An LV lock is acquired before the LV is activated, and is released after the LV is deactivated. If the LV lock cannot be acquired, the LV is not activated. (LV locks are persistent and remain in place when the activation command is done. Global and VG locks are transient, and are held only while an LVM command is running.) - +.P .I lock retries - +.P If a request for a global or VG lock fails due to a lock conflict with another host, lvmlockd automatically retries for a short time before returning a failure to the LVM command. If those retries are @@ -438,25 +434,24 @@ insufficient, the LVM command will retry the entire lock request a number of times specified by global/lvmlockd_lock_retries before failing. If a request for an LV lock fails due to a lock conflict, the command fails immediately. - - -.SS managing the global lock in sanlock VGs - +. +.SS Managing the global lock in sanlock VGs +. The global lock exists in one of the sanlock VGs. The first sanlock VG created will contain the global lock. Subsequent sanlock VGs will each contain a disabled global lock that can be enabled later if necessary. - +.P The VG containing the global lock must be visible to all hosts using sanlock VGs. For this reason, it can be useful to create a small sanlock VG, visible to all hosts, and dedicated to just holding the global lock. While not required, this strategy can help to avoid difficulty in the future if VGs are moved or removed. - +.P The vgcreate command typically acquires the global lock, but in the case of the first sanlock VG, there will be no global lock to acquire until the first vgcreate is complete. So, creating the first sanlock VG is a special case that skips the global lock. - +.P vgcreate determines that it's creating the first sanlock VG when no other sanlock VGs are visible on the system. It is possible that other sanlock VGs do exist, but are not visible when vgcreate checks for them. In this @@ -464,51 +459,49 @@ case, vgcreate will create a new sanlock VG with the global lock enabled. When the another VG containing a global lock appears, lvmlockd will then see more than one VG with a global lock enabled. LVM commands will report that there are duplicate global locks. - +.P If the situation arises where more than one sanlock VG contains a global lock, the global lock should be manually disabled in all but one of them with the command: - +.P lvmlockctl --gl-disable <vgname> - +.P (The one VG with the global lock enabled must be visible to all hosts.) - +.P An opposite problem can occur if the VG holding the global lock is removed. In this case, no global lock will exist following the vgremove, and subsequent LVM commands will fail to acquire it. In this case, the global lock needs to be manually enabled in one of the remaining sanlock VGs with the command: - +.P lvmlockctl --gl-enable <vgname> - +.P (Using a small sanlock VG dedicated to holding the global lock can avoid the case where the global lock must be manually enabled after a vgremove.) - - -.SS internal lvmlock LV - +. +.SS Internal lvmlock LV +. A sanlock VG contains a hidden LV called "lvmlock" that holds the sanlock locks. vgreduce cannot yet remove the PV holding the lvmlock LV. To remove this PV, change the VG lock type to "none", run vgreduce, then change the VG lock type back to "sanlock". Similarly, pvmove cannot be used on a PV used by the lvmlock LV. - +.P To place the lvmlock LV on a specific device, create the VG with only that device, then use vgextend to add other devices. - - +. .SS LV activation - +. In a shared VG, LV activation involves locking through lvmlockd, and the following values are possible with lvchange/vgchange -a: - +.P .IP \fBy\fP|\fBey\fP The command activates the LV in exclusive mode, allowing a single host to activate the LV. Before activating the LV, the command uses lvmlockd to acquire an exclusive lock on the LV. If the lock cannot be acquired, the LV is not activated and an error is reported. This would happen if the LV is active on another host. - +. .IP \fBsy\fP The command activates the LV in shared mode, allowing multiple hosts to activate the LV concurrently. Before activating the LV, the @@ -521,14 +514,13 @@ The shared mode is intended for a multi-host/cluster application or file system. LV types that cannot be used concurrently from multiple hosts include thin, cache, raid, mirror, and snapshot. - +. .IP \fBn\fP The command deactivates the LV. After deactivating the LV, the command uses lvmlockd to release the current lock on the LV. - - -.SS manually repairing a shared VG - +. +.SS Manually repairing a shared VG +. Some failure conditions may not be repairable while the VG has a shared lock type. In these cases, it may be possible to repair the VG by forcibly changing the lock type to "none". This is done by adding @@ -536,10 +528,9 @@ forcibly changing the lock type to "none". This is done by adding vgchange --lock-type none VG. The VG lockspace should first be stopped on all hosts, and be certain that no hosts are using the VG before this is done. - - -.SS recover from lost PV holding sanlock locks - +. +.SS Recover from lost PV holding sanlock locks +. In a sanlock VG, the sanlock locks are held on the hidden "lvmlock" LV. If the PV holding this LV is lost, a new lvmlock LV needs to be created. To do this, ensure no hosts are using the VG, then forcibly change the @@ -547,12 +538,11 @@ lock type to "none" (see above). Then change the lock type back to "sanlock" with the normal command for changing the lock type: vgchange --lock-type sanlock VG. This recreates the internal lvmlock LV with the necessary locks. - - -.SS locking system failures - +. +.SS Locking system failures +. .B lvmlockd failure - +.P If lvmlockd fails or is killed while holding locks, the locks are orphaned in the lock manager. Orphaned locks must be cleared or adopted before the associated resources can be accessed normally. If lock adoption is @@ -561,53 +551,53 @@ instance of lvmlockd will then adopt locks orphaned by the previous instance. Adoption must be enabled in both instances (--adopt|-A 1). Without adoption, the lock manager or host would require a reset to clear orphaned lock state. - +.P .B dlm/corosync failure - +.P If dlm or corosync fail, the clustering system will fence the host using a method configured within the dlm/corosync clustering environment. - +.P LVM commands on other hosts will be blocked from acquiring any locks until the dlm/corosync recovery process is complete. - +.P .B sanlock lease storage failure - +.P If the PV under a sanlock VG's lvmlock LV is disconnected, unresponsive or too slow, sanlock cannot renew the lease for the VG's locks. After some time, the lease will expire, and locks that the host owns in the VG can be acquired by other hosts. The VG must be forcibly deactivated on the host with the expiring lease before other hosts can acquire its locks. This is necessary for data protection. - +.P When the sanlock daemon detects that VG storage is lost and the VG lease is expiring, it runs the command lvmlockctl --kill <vgname>. This command emits a syslog message stating that storage is lost for the VG, and that LVs in the VG must be immediately deactivated. - +.P If no LVs are active in the VG, then the VG lockspace will be removed, and errors will be reported when trying to use the VG. Use the lvmlockctl --drop command to clear the stale lockspace from lvmlockd. - +.P If the VG has active LVs, they must be quickly deactivated before the locks expire. After all LVs are deactivated, run lvmlockctl --drop <vgname> to clear the expiring lockspace from lvmlockd. - +.P If all LVs in the VG are not deactivated within about 40 seconds, sanlock uses wdmd and the local watchdog to reset the host. The machine reset is effectively a severe form of "deactivating" LVs before they can be activated on other hosts. The reset is considered a better alternative than having LVs used by multiple hosts at once, which could easily damage or destroy their content. - +.P .B sanlock lease storage failure automation - +.P When the sanlock daemon detects that the lease storage is lost, it runs the command lvmlockctl --kill <vgname>. This lvmlockctl command can be configured to run another command to forcibly deactivate LVs, taking the place of the manual process described above. The other command is configured in the lvm.conf lvmlockctl_kill_command setting. The VG name is appended to the end of the command specified. - +.P The lvmlockctl_kill_command should forcibly deactivate LVs in the VG, ensuring that existing writes to LVs in the VG are complete and that further writes to the LVs in the VG will be rejected. If it is able to do @@ -616,7 +606,7 @@ with an error. If lvmlockctl --kill gets a successful result from lvmlockctl_kill_command, it tells lvmlockd to drop locks for the VG (the equivalent of running lvmlockctl --drop). If this completes in time, a machine reset can be avoided. - +.P One possible option is to create a script my_vg_kill_script.sh: .nf #!/bin/bash @@ -630,191 +620,181 @@ One possible option is to create a script my_vg_kill_script.sh: fi exit 1 .fi - +.P Set in lvm.conf: .nf lvmlockctl_kill_command="/usr/sbin/my_vg_kill_script.sh" .fi - +.P (The script and dmsetup commands should be tested with the actual VG to ensure that all top level LVs are properly disabled.) - +.P If the lvmlockctl_kill_command is not configured, or fails, lvmlockctl --kill will emit syslog messages as described in the previous section, notifying the user to manually deactivate the VG before sanlock resets the machine. - +.P .B sanlock daemon failure - +.P If the sanlock daemon fails or exits while a lockspace is started, the local watchdog will reset the host. This is necessary to protect any application resources that depend on sanlock leases. - - -.SS changing dlm cluster name - +. +.SS Changing dlm cluster name +. When a dlm VG is created, the cluster name is saved in the VG metadata. To use the VG, a host must be in the named dlm cluster. If the dlm cluster name changes, or the VG is moved to a new cluster, the dlm cluster name saved in the VG must also be changed. - +.P To see the dlm cluster name saved in the VG, use the command: .br vgs -o+locktype,lockargs <vgname> - +.P To change the dlm cluster name in the VG when the VG is still used by the original cluster: - +.P .IP \[bu] 2 Start the VG on the host changing the lock type .br vgchange --lock-start <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Stop the VG on all other hosts: .br vgchange --lock-stop <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Change the VG lock type to none on the host where the VG is started: .br vgchange --lock-type none <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Change the dlm cluster name on the hosts or move the VG to the new cluster. The new dlm cluster must now be running on the host. Verify the new name by: .br cat /sys/kernel/config/dlm/cluster/cluster_name - -.IP \[bu] 2 +. +.IP \[bu] Change the VG lock type back to dlm which sets the new cluster name: .br vgchange --lock-type dlm <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Start the VG on hosts to use it: .br vgchange --lock-start <vgname> - .P - To change the dlm cluster name in the VG when the dlm cluster name has already been changed on the hosts, or the VG has already moved to a different cluster: - +. .IP \[bu] 2 Ensure the VG is not being used by any hosts. - -.IP \[bu] 2 +. +.IP \[bu] The new dlm cluster must be running on the host making the change. The current dlm cluster name can be seen by: .br cat /sys/kernel/config/dlm/cluster/cluster_name - -.IP \[bu] 2 +. +.IP \[bu] Change the VG lock type to none: .br vgchange --lock-type none --lock-opt force <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Change the VG lock type back to dlm which sets the new cluster name: .br vgchange --lock-type dlm <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Start the VG on hosts to use it: .br vgchange --lock-start <vgname> - - -.SS changing a local VG to a shared VG - +. +.SS Changing a local VG to a shared VG +. All LVs must be inactive to change the lock type. - +.P lvmlockd must be configured and running as described in USAGE. - +. .IP \[bu] 2 Change a local VG to a shared VG with the command: .br vgchange --lock-type sanlock|dlm <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Start the VG on hosts to use it: .br vgchange --lock-start <vgname> - -.P - -.SS changing a shared VG to a local VG - +. +.SS Changing a shared VG to a local VG +. All LVs must be inactive to change the lock type. - +.P .IP \[bu] 2 Start the VG on the host making the change: .br vgchange --lock-start <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Stop the VG on all other hosts: .br vgchange --lock-stop <vgname> - -.IP \[bu] 2 +. +.IP \[bu] Change the VG lock type to none on the host where the VG is started: .br vgchange --lock-type none <vgname> - .P - If the VG cannot be started with the previous lock type, then the lock type can be forcibly changed to none with: - +.br vgchange --lock-type none --lock-opt force <vgname> - +.P To change a VG from one lock type to another (i.e. between sanlock and dlm), first change it to a local VG, then to the new type. - - -.SS changing a clvm/clustered VG to a shared VG - +. +.SS Changing a clvm/clustered VG to a shared VG +. All LVs must be inactive to change the lock type. - +.P First change the clvm/clustered VG to a local VG. Within a running clvm cluster, change a clustered VG to a local VG with the command: - +.P vgchange -cn <vgname> - +.P If the clvm cluster is no longer running on any nodes, then extra options can be used to forcibly make the VG local. Caution: this is only safe if all nodes have stopped using the VG: - +.P vgchange --lock-type none --lock-opt force <vgname> - +.P After the VG is local, follow the steps described in "changing a local VG to a shared VG". - -.SS extending an LV active on multiple hosts - +. +.SS Extending an LV active on multiple hosts +. With lvmlockd and dlm, a special clustering procedure is used to refresh a shared LV on remote cluster nodes after it has been extended on one node. - +.P When an LV holding gfs2 or ocfs2 is active on multiple hosts with a shared lock, lvextend is permitted to run with an existing shared LV lock in place of the normal exclusive LV lock. - +.P After lvextend has finished extending the LV, it sends a remote request to other nodes running the dlm to run 'lvchange --refresh' on the LV. This uses dlm_controld and corosync features. - +.P Some special --lockopt values can be used to modify this process. "shupdate" permits the lvextend update with an existing shared lock if it isn't otherwise permitted. "norefresh" prevents the remote refresh operation. - - -.SS limitations of shared VGs - +. +.SS Limitations of shared VGs +. Things that do not yet work in shared VGs: .br \[bu] @@ -831,72 +811,74 @@ pvmove of entire PVs, or under LVs activated with shared locks .br \[bu] vgsplit and vgmerge (convert to a local VG to do this) - - +. .SS lvmlockd changes from clvmd - +. (See above for converting an existing clvm VG to a shared VG.) - +.P While lvmlockd and clvmd are entirely different systems, LVM command usage remains similar. Differences are more notable when using lvmlockd's sanlock option. - +.P Visible usage differences between shared VGs (using lvmlockd) and clvm/clustered VGs (using clvmd): - +. .IP \[bu] 2 lvm.conf is configured to use lvmlockd by setting use_lvmlockd=1. clvmd used locking_type=3. - -.IP \[bu] 2 +. +.IP \[bu] vgcreate --shared creates a shared VG. vgcreate --clustered y created a clvm/clustered VG. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd adds the option of using sanlock for locking, avoiding the need for network clustering. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd defaults to the exclusive activation mode whenever the activation mode is unspecified, i.e. -ay means -aey, not -asy. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd commands always apply to the local host, and never have an effect on a remote host. (The activation option 'l' is not used.) - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd saves the cluster name for a shared VG using dlm. Only hosts in the matching cluster can use the VG. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd requires starting/stopping shared VGs with vgchange --lock-start and --lock-stop. - -.IP \[bu] 2 +. +.IP \[bu] vgremove of a sanlock VG may fail indicating that all hosts have not stopped the VG lockspace. Stop the VG on all hosts using vgchange --lock-stop. - -.IP \[bu] 2 +. +.IP \[bu] vgreduce or pvmove of a PV in a sanlock VG will fail if it holds the internal "lvmlock" LV that holds the sanlock locks. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd uses lock retries instead of lock queueing, so high lock contention may require increasing global/lvmlockd_lock_retries to avoid transient lock failures. - -.IP \[bu] 2 +. +.IP \[bu] lvmlockd includes VG reporting options lock_type and lock_args, and LV reporting option lock_args to view the corresponding metadata fields. - -.IP \[bu] 2 +. +.IP \[bu] In the 'vgs' command's sixth VG attr field, "s" for "shared" is displayed for shared VGs. - -.IP \[bu] 2 +. +.IP \[bu] If lvmlockd fails or is killed while in use, locks it held remain but are orphaned in the lock manager. lvmlockd can be restarted with an option to adopt the orphan locks from the previous instance of lvmlockd. - -.P +. +.SH SEE ALSO +. +.BR lvm (8), +.BR lvmlockctl (8) diff --git a/man/lvmpolld.8_main b/man/lvmpolld.8_main index 4fe149094..885c4a2ea 100644 --- a/man/lvmpolld.8_main +++ b/man/lvmpolld.8_main @@ -1,10 +1,16 @@ .TH LVMPOLLD 8 "LVM TOOLS #VERSION#" "Red Hat Inc" \" -*- nroff -*- +. .SH NAME +. lvmpolld \(em LVM poll daemon +. .SH SYNOPSIS +. .B lvmpolld +.nh +.ad l .RB [ -l | --log -.RI { all | wire | debug }] +.BR all | wire | debug ] .RB [ -p | --pidfile .IR pidfile_path ] .RB [ -s | --socket @@ -16,75 +22,91 @@ lvmpolld \(em LVM poll daemon .RB [ -f | --foreground ] .RB [ -h | --help ] .RB [ -V | --version ] - +.ad b +.hy +.P .B lvmpolld .RB [ --dump ] +. .SH DESCRIPTION +. lvmpolld is polling daemon for LVM. The daemon receives requests for polling of already initialised operations originating in LVM2 command line tool. The requests for polling originate in the \fBlvconvert\fP, \fBpvmove\fP, \fBlvchange\fP or \fBvgchange\fP LVM2 commands. - +.P The purpose of lvmpolld is to reduce the number of spawned background processes per otherwise unique polling operation. There should be only one. It also eliminates the possibility of unsolicited termination of background process by external factors. - +.P lvmpolld is used by LVM only if it is enabled in \fBlvm.conf\fP(5) by specifying the \fBglobal/use_lvmpolld\fP setting. If this is not defined in the LVM configuration explicitly then default setting is used instead (see the output of \fBlvmconfig --type default global/use_lvmpolld\fP command). +. .SH OPTIONS - +. To run the daemon in a test environment both the pidfile_path and the socket_path should be changed from the defaults. +. .TP -.BR -f ", " --foreground +.BR -f | --foreground Don't fork, but run in the foreground. .TP -.BR -h ", " --help +.BR -h | --help Show help information. +. .TP -.IR \fB-l\fP ", " \fB--log\fP " {" all | wire | debug } +.BR -l | --log " " all | wire | debug Select the type of log messages to generate. Messages are logged by syslog. -Additionally, when -f is given they are also sent to standard error. -There are two classes of messages: wire and debug. Selecting 'all' supplies both -and is equivalent to a comma-separated list -l wire,debug. +Additionally, when \fB-f\fP is given they are also sent to standard error. +There are two classes of messages: wire and debug. Selecting '\fBall\fP' supplies both +and is equivalent to a comma-separated list \fB-l wire,debug\fP. +. .TP -.BR -p ", " --pidfile " " \fIpidfile_path +.BR -p | --pidfile " " \fIpidfile_path Path to the pidfile. This overrides both the built-in default (#DEFAULT_PID_DIR#/lvmpolld.pid) and the environment variable \fBLVM_LVMPOLLD_PIDFILE\fP. This file is used to prevent more than one instance of the daemon running simultaneously. +. .TP -.BR -s ", " --socket " " \fIsocket_path +.BR -s | --socket " " \fIsocket_path Path to the socket file. This overrides both the built-in default (#DEFAULT_RUN_DIR#/lvmpolld.socket) and the environment variable \fBLVM_LVMPOLLD_SOCKET\fP. +. .TP -.BR -t ", " --timeout " " \fItimeout_value +.BR -t | --timeout " " \fItimeout_value The daemon may shutdown after being idle for the given time (in seconds). When the option is omitted or the value given is zero the daemon never shutdowns on idle. +. .TP -.BR -B ", " --binary " " \fIlvm_binary_path +.BR -B | --binary " " \fIlvm_binary_path Optional path to alternative LVM binary (default: #LVM_PATH#). Use for testing purposes only. +. .TP -.BR -V ", " --version +.BR -V | --version Display the version of lvmpolld daemon. .TP .B --dump Contact the running lvmpolld daemon to obtain the complete state and print it out in a raw format. +. .SH ENVIRONMENT VARIABLES +. .TP .B LVM_LVMPOLLD_PIDFILE Path for the pid file. +. .TP .B LVM_LVMPOLLD_SOCKET Path for the socket file. - +. .SH SEE ALSO +. .BR lvm (8), .BR lvm.conf (5) diff --git a/man/lvmreport.7_main b/man/lvmreport.7_main index d6943b9df..c13e7789c 100644 --- a/man/lvmreport.7_main +++ b/man/lvmreport.7_main @@ -874,7 +874,7 @@ segs_sort="vg_name,lv_name,seg_start" .nf # pvs - PV VG Fmt Attr PSize PFree + PV VG Fmt Attr PSize PFree /dev/sda vg lvm2 a-- 100.00m 88.00m /dev/sdb vg lvm2 a-- 100.00m 92.00m @@ -889,13 +889,13 @@ segs_sort="vg_name,lv_name,seg_start" /dev/sdb vg lvm2 a-- 100.00m 92.00m 2 23 # vgs - VG #PV #LV #SN Attr VSize VFree + VG #PV #LV #SN Attr VSize VFree vg 2 2 0 wz--n- 200.00m 180.00m # lvs LV VG Attr LSize Pool Origin Move Log Cpy%Sync Convert - lvol0 vg -wi-a----- 4.00m - lvol1 vg rwi-a-r--- 4.00m 100.00 + lvol0 vg -wi-a----- 4.00m + lvol1 vg rwi-a-r--- 4.00m 100.00 # lvs --segments LV VG Attr #Str Type SSize @@ -917,8 +917,8 @@ lvs_sort="-lv_time" # lvs LV LSize Origin Pool Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m .fi You can use \fB-o|--options\fP command line option to override current @@ -931,18 +931,18 @@ configuration directly on command line. lvol0 4.00m # lvs -o+lv_layout - LV LSize Origin Pool Cpy%Sync Layout + LV LSize Origin Pool Cpy%Sync Layout lvol1 4.00m 100.00 raid,raid1 - lvol0 4.00m linear + lvol0 4.00m linear # lvs -o-origin LV LSize Pool Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m # lvs -o lv_name,lv_size,origin -o+lv_layout -o-origin -O lv_name - LV LSize Layout - lvol0 4.00m linear + LV LSize Layout + lvol0 4.00m linear lvol1 4.00m raid,raid1 .fi @@ -1012,11 +1012,11 @@ compact_output=1 # lvs LV LSize Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m # lvs vg/lvol0 - LV LSize + LV LSize lvol0 4.00m .fi @@ -1031,17 +1031,17 @@ compact_output_cols="origin" # lvs LV LSize Pool Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m # lvs vg/lvol0 - LV LSize Pool - lvol0 4.00m + LV LSize Pool + lvol0 4.00m -# lvs -o#pool_lv +# lvs -o#pool_lv LV LSize Origin Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m .fi We will use \fBreport/compact_output=1\fP for subsequent examples. @@ -1057,8 +1057,8 @@ configuration setting (or \fB--nosuffix\fP command line option) to change this. .nf # lvs --units b --nosuffix LV LSize Cpy%Sync - lvol1 4194304 100.00 - lvol0 4194304 + lvol1 4194304 100.00 + lvol0 4194304 .fi If you want to configure whether report headings are displayed or not, use @@ -1067,8 +1067,8 @@ line option). .nf # lvs --noheadings - lvol1 4.00m 100.00 - lvol0 4.00m + lvol1 4.00m 100.00 + lvol0 4.00m .fi In some cases, it may be useful to display report content as key=value pairs @@ -1124,12 +1124,12 @@ properly. # lvs --separator " | " LV | LSize | Cpy%Sync lvol1 | 4.00m | 100.00 - lvol0 | 4.00m | + lvol0 | 4.00m | # lvs --separator " | " --aligned LV | LSize | Cpy%Sync - lvol1 | 4.00m | 100.00 - lvol0 | 4.00m | + lvol1 | 4.00m | 100.00 + lvol0 | 4.00m | .fi Let's display one one more field in addition ("lv_tags" in this example) @@ -1137,8 +1137,8 @@ for the lvs report output. .nf # lvs -o+lv_tags - LV LSize Cpy%Sync LV Tags - lvol1 4.00m 100.00 + LV LSize Cpy%Sync LV Tags + lvol1 4.00m 100.00 lvol0 4.00m tagA,tagB .fi @@ -1152,8 +1152,8 @@ definition. list_item_separator=";" # lvs -o+tags - LV LSize Cpy%Sync LV Tags - lvol1 4.00m 100.00 + LV LSize Cpy%Sync LV Tags + lvol1 4.00m 100.00 lvol0 4.00m tagA;tagB .fi @@ -1169,9 +1169,9 @@ and time is displayed, including timezone. time_format="%Y-%m-%d %T %z" # lvs -o+time - LV LSize Cpy%Sync CTime - lvol1 4.00m 100.00 2016-08-29 12:53:36 +0200 - lvol0 4.00m 2016-08-29 10:15:17 +0200 + LV LSize Cpy%Sync CTime + lvol1 4.00m 100.00 2016-08-29 12:53:36 +0200 + lvol0 4.00m 2016-08-29 10:15:17 +0200 .fi We can change time format in similar way as we do when using \fBdate\fP(1) @@ -1185,9 +1185,9 @@ below, we decided to use %s for number of seconds since Epoch (1970-01-01 UTC). time_format="%s" # lvs - LV Attr LSize Cpy%Sync LV Tags CTime - lvol1 rwi-a-r--- 4.00m 100.00 1472468016 - lvol0 -wi-a----- 4.00m tagA,tagB 1472458517 + LV Attr LSize Cpy%Sync LV Tags CTime + lvol1 rwi-a-r--- 4.00m 100.00 1472468016 + lvol0 -wi-a----- 4.00m tagA,tagB 1472458517 .fi The \fBlvs\fP does not display hidden LVs by default - to include these LVs @@ -1197,12 +1197,12 @@ these hidden LVs are displayed within square brackets. .nf # lvs -a LV LSize Cpy%Sync - lvol1 4.00m 100.00 - [lvol1_rimage_0] 4.00m - [lvol1_rmeta_0] 4.00m - [lvol1_rimage_1] 4.00m - [lvol1_rmeta_1] 4.00m - lvol0 4.00m + lvol1 4.00m 100.00 + [lvol1_rimage_0] 4.00m + [lvol1_rmeta_0] 4.00m + [lvol1_rimage_1] 4.00m + [lvol1_rmeta_1] 4.00m + lvol0 4.00m .fi You can configure LVM to display the square brackets for hidden LVs or not with @@ -1214,12 +1214,12 @@ mark_hidden_devices=0 # lvs -a LV LSize Cpy%Sync - lvol1 4.00m 100.00 - lvol1_rimage_0 4.00m - lvol1_rmeta_0 4.00m - lvol1_rimage_1 4.00m - lvol1_rmeta_1 4.00m - lvol0 4.00m + lvol1 4.00m 100.00 + lvol1_rimage_0 4.00m + lvol1_rmeta_0 4.00m + lvol1_rimage_1 4.00m + lvol1_rmeta_1 4.00m + lvol0 4.00m .fi It's not recommended to use LV marks for hidden devices to decide whether the @@ -1229,13 +1229,13 @@ used by LVM only and they should not be accessed directly by end users. .nf # lvs -a -o+lv_role - LV LSize Cpy%Sync Role - lvol1 4.00m 100.00 public - lvol1_rimage_0 4.00m private,raid,image + LV LSize Cpy%Sync Role + lvol1 4.00m 100.00 public + lvol1_rimage_0 4.00m private,raid,image lvol1_rmeta_0 4.00m private,raid,metadata - lvol1_rimage_1 4.00m private,raid,image + lvol1_rimage_1 4.00m private,raid,image lvol1_rmeta_1 4.00m private,raid,metadata - lvol0 4.00m public + lvol0 4.00m public .fi Some of the reporting fields that LVM reports are of binary nature. For such @@ -1245,7 +1245,7 @@ undefined). .nf # lvs -o+lv_active_locally - LV LSize Cpy%Sync ActLocal + LV LSize Cpy%Sync ActLocal lvol1 4.00m 100.00 active locally lvol0 4.00m active locally .fi @@ -1258,7 +1258,7 @@ We can change the way how these binary values are displayed with binary_values_as_numeric=1 # lvs -o+lv_active_locally - LV LSize Cpy%Sync ActLocal + LV LSize Cpy%Sync ActLocal lvol1 4.00m 100.00 1 lvol0 4.00m 1 .fi @@ -1342,11 +1342,11 @@ addition to lvol0 and lvol1 we used in our previous examples. .nf # lvs -o name,size,origin,snap_percent,tags,time - LV LSize Origin Snap% LV Tags CTime - lvol4 4.00m lvol2 24.61 2016-09-09 16:57:44 +0200 - lvol3 4.00m lvol2 5.08 2016-09-09 16:56:48 +0200 - lvol2 8.00m tagA,tagC,tagD 2016-09-09 16:55:12 +0200 - lvol1 4.00m 2016-08-29 12:53:36 +0200 + LV LSize Origin Snap% LV Tags CTime + lvol4 4.00m lvol2 24.61 2016-09-09 16:57:44 +0200 + lvol3 4.00m lvol2 5.08 2016-09-09 16:56:48 +0200 + lvol2 8.00m tagA,tagC,tagD 2016-09-09 16:55:12 +0200 + lvol1 4.00m 2016-08-29 12:53:36 +0200 lvol0 4.00m tagA,tagB 2016-08-29 10:15:17 +0200 .fi @@ -1359,29 +1359,29 @@ together. .nf # lvs -o name,size,snap_percent -S 'size=8m' - LV LSize + LV LSize lvol2 8.00m # lvs -o name,size,snap_percent -S 'size=8' - LV LSize + LV LSize lvol2 8.00m # lvs -o name,size,snap_percent -S 'size < 5000k' - LV LSize Snap% - lvol4 4.00m 24.61 - lvol3 4.00m 5.08 - lvol1 4.00m - lvol0 4.00m + LV LSize Snap% + lvol4 4.00m 24.61 + lvol3 4.00m 5.08 + lvol1 4.00m + lvol0 4.00m # lvs -o name,size,snap_percent -S 'size < 5000k && snap_percent > 20' - LV LSize Snap% - lvol4 4.00m 24.61 + LV LSize Snap% + lvol4 4.00m 24.61 # lvs -o name,size,snap_percent \\ -S '(size < 5000k && snap_percent > 20%) || name=lvol2' - LV LSize Snap% - lvol4 4.00m 24.61 - lvol2 8.00m + LV LSize Snap% + lvol4 4.00m 24.61 + lvol2 8.00m .fi You can also use selection together with processing-oriented commands. @@ -1409,14 +1409,14 @@ that matches. If the subset has only one item, we can leave out { }. .nf # lvs -o name,tags -S 'tags={tagA}' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD - lvol0 tagA,tagB - + lvol0 tagA,tagB + # lvs -o name,tags -S 'tags=tagA' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD - lvol0 tagA,tagB + lvol0 tagA,tagB .fi Depending on whether we use "&&" (or ",") or "||" ( or "#") as delimiter @@ -1425,23 +1425,23 @@ we either match subset ("&&" or ",") or even intersection ("||" or "#"). .nf # lvs -o name,tags -S 'tags={tagA,tagC,tagD}' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD # lvs -o name,tags -S 'tags={tagA || tagC || tagD}' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD - lvol0 tagA,tagB + lvol0 tagA,tagB .fi To match the complete set, use [ ] with "&&" (or ",") as delimiter for items. Also note that the order in which we define items in the set is not relevant. .nf -# lvs -o name,tags -S 'tags=[tagA]' +# lvs -o name,tags -S 'tags=[tagA]' # lvs -o name,tags -S 'tags=[tagB,tagA]' - LV LV Tags + LV LV Tags lvol0 tagA,tagB .fi @@ -1449,9 +1449,9 @@ If you use [ ] with "||" (or "#"), this is exactly the same as using { }. .nf # lvs -o name,tags -S 'tags=[tagA || tagC || tagD]' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD - lvol0 tagA,tagB + lvol0 tagA,tagB .fi To match a set with no items, use "" to denote this (note that we have @@ -1460,15 +1460,15 @@ the example below because it's blank and so it gets compacted). .nf # lvs -o name,tags -S 'tags=""' - LV + LV lvol4 lvol3 lvol1 # lvs -o name,tags -S 'tags!=""' - LV LV Tags + LV LV Tags lvol2 tagA,tagC,tagD - lvol0 tagA,tagB + lvol0 tagA,tagB .fi When doing selection based on time fields, we can use either standard, @@ -1477,40 +1477,40 @@ are using standard forms. .nf # lvs -o name,time - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time -S 'time since "2016-09-01"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 # lvs -o name,time -S 'time since "2016-09-09 16:56"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 # lvs -o name,time -S 'time since "2016-09-09 16:57:30"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 -# lvs -o name,time \\ +# lvs -o name,time \\ -S 'time since "2016-08-29" && time until "2016-09-09 16:55:12"' - LV CTime - lvol2 2016-09-09 16:55:12 +0200 - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol2 2016-09-09 16:55:12 +0200 + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time \\ -S 'time since "2016-08-29" && time before "2016-09-09 16:55:12"' - LV CTime - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 .fi Time operators have synonyms: ">=" for since, "<=" for until, @@ -1519,75 +1519,75 @@ Time operators have synonyms: ">=" for since, "<=" for until, .nf # lvs -o name,time \\ -S 'time >= "2016-08-29" && time <= "2016-09-09 16:55:30"' - LV CTime - lvol2 2016-09-09 16:55:12 +0200 - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol2 2016-09-09 16:55:12 +0200 + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time \\ -S 'time since "2016-08-29" && time < "2016-09-09 16:55:12"' - LV CTime - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 .fi Example below demonstrates using absolute time expression. .nf # lvs -o name,time --config report/time_format="%s" - LV CTime - lvol4 1473433064 - lvol3 1473433008 - lvol2 1473432912 - lvol1 1472468016 - lvol0 1472458517 + LV CTime + lvol4 1473433064 + lvol3 1473433008 + lvol2 1473432912 + lvol1 1472468016 + lvol0 1472458517 # lvs -o name,time -S 'time since @1473433008' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 .fi Examples below demonstrates using freeform time expressions. .nf # lvs -o name,time -S 'time since "2 weeks ago"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time -S 'time since "1 week ago"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 # lvs -o name,time -S 'time since "2 weeks ago"' - LV CTime - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time -S 'time before "1 week ago"' - LV CTime - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 # lvs -o name,time -S 'time since "68 hours ago"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 # lvs -o name,time -S 'time since "1 year 3 months ago"' - LV CTime - lvol4 2016-09-09 16:57:44 +0200 - lvol3 2016-09-09 16:56:48 +0200 - lvol2 2016-09-09 16:55:12 +0200 - lvol1 2016-08-29 12:53:36 +0200 - lvol0 2016-08-29 10:15:17 +0200 + LV CTime + lvol4 2016-09-09 16:57:44 +0200 + lvol3 2016-09-09 16:56:48 +0200 + lvol2 2016-09-09 16:55:12 +0200 + lvol1 2016-08-29 12:53:36 +0200 + lvol0 2016-08-29 10:15:17 +0200 .fi .SS Command log reporting @@ -1615,9 +1615,9 @@ command_log_selection="!(log_type=status && message=success)" Logical Volume ============== LV LSize Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m - + lvol1 4.00m 100.00 + lvol0 4.00m + Command Log =========== Seq LogType Context ObjType ObjName ObjGrp Msg Errno RetCode @@ -1638,9 +1638,9 @@ command_log_selection="all" Logical Volume ============== LV LSize Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m - + lvol1 4.00m 100.00 + lvol0 4.00m + Command Log =========== Seq LogType Context ObjType ObjName ObjGrp Msg Errno RetCode @@ -1670,7 +1670,7 @@ To configure the log report directly on command line, we need to use LV LSize lvol1 4.00m lvol0 4.00m - + Command Log =========== ObjType ObjName Msg RetCode @@ -1763,9 +1763,9 @@ lvm> lvs Logical Volume ============== LV LSize Cpy%Sync - lvol1 4.00m 100.00 - lvol0 4.00m - + lvol1 4.00m 100.00 + lvol0 4.00m + Command Log =========== Seq LogType Context ObjType ObjName ObjGrp Msg Errno RetCode @@ -1774,7 +1774,7 @@ lvm> lvs 3 status processing vg vg success 0 1 4 status shell cmd lvs success 0 1 -lvm> lastlog +lvm> lastlog Command Log =========== Seq LogType Context ObjType ObjName ObjGrp Msg Errno RetCode diff --git a/man/lvmsadc.8_main b/man/lvmsadc.8_main index c2781b8cb..039ff7bca 100644 --- a/man/lvmsadc.8_main +++ b/man/lvmsadc.8_main @@ -1,12 +1,20 @@ .TH "LVMSADC" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" -.SH "NAME" +. +.SH NAME +. lvmsadc \(em LVM system activity data collector -.SH "SYNOPSIS" +. +.SH SYNOPSIS +. .B lvmsadc -.SH "DESCRIPTION" +. +.SH DESCRIPTION +. lvmsadc is not supported under LVM2. The device-mapper statistics facility provides similar performance metrics using the \fBdmstats(8)\fP command. -.SH "SEE ALSO" -.BR dmstats (8) +. +.SH SEE ALSO +. +.BR dmstats (8), .BR lvm (8) diff --git a/man/lvmsar.8_main b/man/lvmsar.8_main index 0bbcbf37d..4c3f14bf7 100644 --- a/man/lvmsar.8_main +++ b/man/lvmsar.8_main @@ -1,12 +1,20 @@ .TH "LVMSAR" "8" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" -.SH "NAME" +. +.SH NAME +. lvmsar \(em LVM system activity reporter -.SH "SYNOPSIS" +. +.SH SYNOPSIS +. .B lvmsar -.SH "DESCRIPTION" +. +.SH DESCRIPTION +. lvmsar is not supported under LVM2. The device-mapper statistics facility provides similar performance metrics using the \fBdmstats(8)\fP command. -.SH "SEE ALSO" -.BR dmstats (8) +. +.SH SEE ALSO +. +.BR dmstats (8), .BR lvm (8) diff --git a/man/lvmsystemid.7_main b/man/lvmsystemid.7_main index 7d6e96ed6..eac4f7bc1 100644 --- a/man/lvmsystemid.7_main +++ b/man/lvmsystemid.7_main @@ -1,38 +1,39 @@ .TH "LVMSYSTEMID" "7" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" - +. .SH NAME +. lvmsystemid \(em LVM system ID - +. .SH DESCRIPTION - +. The \fBlvm\fP(8) system ID restricts Volume Group (VG) access to one host. This is useful when a VG is placed on shared storage devices, or when local devices are visible to both host and guest operating systems. In cases like these, a VG can be visible to multiple hosts at once, and some mechanism is needed to protect it from being used by more than one host at a time. - +.P A VG's system ID identifies one host as the VG owner. The host with a matching system ID can use the VG and its LVs, while LVM on other hosts will ignore it. This protects the VG from being accidentally used from other hosts. - +.P The system ID is a string that uniquely identifies a host. It can be configured as a custom value, or it can be assigned automatically by LVM using some unique identifier already available on the host, e.g. machine-id or uname. - +.P When a new VG is created, the system ID of the local host is recorded in the VG metadata. The creating host then owns the new VG, and LVM on other hosts will ignore it. When an existing, exported VG is imported (vgimport), the system ID of the local host is saved in the VG metadata, and the importing host owns the VG. - +.P A VG without a system ID can be used by LVM on any host where the VG's devices are visible. When system IDs are not used, device filters should be configured on all hosts to exclude the VG's devices from all but one host. - +.P A .B foreign VG is a VG seen by a host with an unmatching system ID, i.e. the system ID @@ -40,195 +41,194 @@ in the VG metadata does not match the system ID configured on the host. If the host has no system ID, and the VG does, the VG is foreign and LVM will ignore it. If the VG has no system ID, access is unrestricted, and LVM can access it from any host, whether the host has a system ID or not. - +.P Changes to a host's system ID and a VG's system ID can be made in limited circumstances (see vgexport and vgimport). Improper changes can result in a host losing access to its VG, or a VG being accidentally damaged by access from an unintended host. Even limited changes to the VG system ID may not be perfectly reflected across hosts. A more coherent view of shared storage requires an inter-host locking system to coordinate access. - +.P Valid system ID characters are the same as valid VG name characters. If a system ID contains invalid characters, those characters are omitted and remaining characters are used. If a system ID is longer than the maximum name length, the characters up to the maximum length are used. The maximum length of a system ID is 128 characters. - +.P Print the system ID of a VG to check if it is set: - +.P .B vgs -o systemid .I VG - +.P Print the system ID of the local host to check if it is configured: - +.P .B lvm systemid - +. .SS Limitations and warnings - +. To benefit fully from system ID, all hosts should have a system ID configured, and all VGs should have a system ID set. Without any method to restrict access, e.g. system ID or device filters, a VG that is visible to multiple hosts can be accidentally damaged or destroyed. - +. .IP \[bu] 2 A VG without a system ID can be used without restriction from any host where it is visible, even from hosts that have a system ID. - -.IP \[bu] 2 +. +.IP \[bu] Many VGs will not have a system ID set because LVM has not enabled it by default, and even when enabled, many VGs were created before the feature was added to LVM or enabled. A system ID can be assigned to these VGs by using vgchange --systemid (see below). - -.IP \[bu] 2 +. +.IP \[bu] Two hosts should not be assigned the same system ID. Doing so defeats the purpose of distinguishing different hosts with this value. - -.IP \[bu] 2 +. +.IP \[bu] Orphan PVs (or unused devices) on shared storage are unprotected by the system ID feature. Commands that use these PVs, such as vgcreate or vgextend, are not prevented from performing conflicting operations and corrupting the PVs. See the .B orphans section for more information. - -.IP \[bu] 2 +. +.IP \[bu] The system ID does not protect devices in a VG from programs other than LVM. - -.IP \[bu] 2 +. +.IP \[bu] A host using an old LVM version (without the system ID feature) will not recognize a system ID set in VGs. The old LVM can read a VG with a system ID, but is prevented from writing to the VG (or its LVs). The system ID feature changes the write mode of a VG, making it appear read-only to previous versions of LVM. - +.sp This also means that if a host downgrades to the old LVM version, it would lose access to any VGs it had created with a system ID. To avoid this, the system ID should be removed from local VGs before downgrading LVM to a version without the system ID feature. - - +. .SS Types of VG access - +. A local VG is meant to be used by a single host. - +.P A shared or clustered VG is meant to be used by multiple hosts. - +.P These can be further distinguished as: - +. +.TP .B Unrestricted: A local VG that has no system ID. This VG type is unprotected and accessible to any host. - +. +.TP .B Owned: A local VG that has a system ID set, as viewed from the host with a matching system ID (the owner). This VG type is accessible to the host. - +. +.TP .B Foreign: A local VG that has a system ID set, as viewed from any host with an unmatching system ID (or no system ID). It is owned by another host. This VG type is not accessible to the host. - +. +.TP .B Exported: A local VG that has been exported with vgexport and has no system ID. This VG type can only be accessed by vgimport which will change it to owned. - +. +.TP .B Shared: A shared or "lockd" VG has the lock_type set and has no system ID. A shared VG is meant to be used on shared storage from multiple hosts, and is only accessible to hosts using lvmlockd. Applicable only if LVM is compiled with lvmlockd support. - +. +.TP .B Clustered: A clustered or "clvm" VG has the clustered flag set and has no system ID. A clustered VG is meant to be used on shared storage from multiple hosts, and is only accessible to hosts using clvmd. Applicable only if LVM is compiled with clvm support. - - -.SS Host system ID configuration - +. +.SS Host system ID configuration +. A host's own system ID can be defined in a number of ways. lvm.conf global/system_id_source defines the method LVM will use to find the local system ID: - +. .TP .B none .br - LVM will not use a system ID. LVM is allowed to access VGs without a system ID, and will create new VGs without a system ID. An undefined system_id_source is equivalent to none. - +.sp .I lvm.conf .nf global { system_id_source = "none" } .fi - +. .TP .B machineid .br - The content of /etc/machine-id is used as the system ID if available. See .BR machine-id (5) and .BR systemd-machine-id-setup (1) to check if machine-id is available on the host. - +.sp .I lvm.conf .nf global { system_id_source = "machineid" } .fi - +. .TP .B uname .br - The string utsname.nodename from .BR uname (2) is used as the system ID. A uname beginning with "localhost" is ignored and equivalent to none. - +.sp .I lvm.conf .nf global { system_id_source = "uname" } .fi - +. .TP .B lvmlocal .br - The system ID is defined in lvmlocal.conf local/system_id. - +.sp .I lvm.conf .nf global { system_id_source = "lvmlocal" } .fi - +.sp .I lvmlocal.conf .nf local { system_id = "example_name" } .fi - +. .TP .B file .br - The system ID is defined in a file specified by lvm.conf global/system_id_file. - +.sp .I lvm.conf .nf global { @@ -236,132 +236,125 @@ global { system_id_file = "/path/to/file" } .fi - .LP - Changing system_id_source will likely cause the system ID of the host to change, which will prevent the host from using VGs that it previously used (see extra_system_ids below to handle this.) - +.P If a system_id_source other than none fails to produce a system ID value, it is the equivalent of having none. The host will be allowed to access VGs with no system ID, but will not be allowed to access VGs with a system ID set. - - +. .SS Overriding system ID - +. In some cases, it may be necessary for a host to access VGs with different system IDs, e.g. if a host's system ID changes, and it wants to use VGs that it created with its old system ID. To allow a host to access VGs with other system IDs, those other system IDs can be listed in lvmlocal.conf local/extra_system_ids. - +.P .I lvmlocal.conf .nf local { extra_system_ids = [ "my_other_name" ] } .fi - +.P A safer option may be configuring the extra values as needed on the command line as: .br \fB--config 'local/extra_system_ids=["\fP\fIid\fP\fB"]'\fP - - +. .SS vgcreate - +. In vgcreate, the host running the command assigns its own system ID to the new VG. To override this and set another system ID: - +.P .B vgcreate --systemid .I SystemID VG PVs - +.P Overriding the host's system ID makes it possible for a host to create a VG that it may not be able to use. Another host with a system ID matching the one specified may not recognize the new VG without manually rescanning devices. - +.P If the --systemid argument is an empty string (""), the VG is created with no system ID, making it accessible to other hosts (see warnings above.) - - +. .SS report/display - +. The system ID of a VG is displayed with the "systemid" reporting option. - +.P Report/display commands ignore foreign VGs by default. To report foreign VGs, the --foreign option can be used. This causes the VGs to be read from disk. - +.P .B vgs --foreign -o +systemid - +.P When a host with no system ID sees foreign VGs, it warns about them as they are skipped. The host should be assigned a system ID, after which standard reporting commands will silently ignore foreign VGs. - - +. .SS vgexport/vgimport - +. vgexport clears the VG system ID when exporting the VG. - +.P vgimport sets the VG system ID to the system ID of the host doing the import. - - +. .SS vgchange - +. A host can change the system ID of its own VGs, but the command requires confirmation because the host may lose access to the VG being changed: - +.P .B vgchange --systemid .I SystemID VG - +.P The system ID can be removed from a VG by specifying an empty string ("") as the new system ID. This makes the VG accessible to other hosts (see warnings above.) - +.P A host cannot directly change the system ID of a foreign VG. - +.P To move a VG from one host to another, vgexport and vgimport should be used. - +.P To forcibly gain ownership of a foreign VG, a host can temporarily add the foreign system ID to its extra_system_ids list, and change the system ID of the foreign VG to its own. See Overriding system ID above. - - +. .SS shared VGs - +. A shared VG has no system ID set, allowing multiple hosts to use it via lvmlockd. Changing a VG to shared will clear the existing system ID. Applicable only if LVM is compiled with lvmlockd support. - - +. .SS clustered VGs - +. A clustered/clvm VG has no system ID set, allowing multiple hosts to use it via clvmd. Changing a VG to clustered will clear the existing system ID. Changing a VG to not clustered will set the system ID to the host running the vgchange command. - - +. .SS creation_host - +. In vgcreate, the VG metadata field creation_host is set by default to the host's uname. The creation_host cannot be changed, and is not used to control access. When system_id_source is "uname", the system_id and creation_host fields will be the same. - +. .SS orphans - +. Orphan PVs are unused devices; they are not currently used in any VG. Because of this, they are not protected by a system ID, and any host can use them. Coordination of changes to orphan PVs is beyond the scope of system ID. The same is true of any block device that is not a PV. - +. .SH SEE ALSO +. +.nh +.ad l .BR vgcreate (8), .BR vgchange (8), .BR vgimport (8), @@ -371,4 +364,3 @@ system ID. The same is true of any block device that is not a PV. .BR lvm.conf (5), .BR machine-id (5), .BR uname (2) - diff --git a/man/lvmthin.7_main b/man/lvmthin.7_main index 9568eca41..0a9d4698f 100644 --- a/man/lvmthin.7_main +++ b/man/lvmthin.7_main @@ -1,33 +1,34 @@ .TH "LVMTHIN" "7" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" - +. .SH NAME +. lvmthin \(em LVM thin provisioning - +. .SH DESCRIPTION - +. Blocks in a standard \fBlvm\fP(8) Logical Volume (LV) are allocated when the LV is created, but blocks in a thin provisioned LV are allocated as they are written. Because of this, a thin provisioned LV is given a virtual size, and can then be much larger than physically available storage. The amount of physical storage provided for thin provisioned LVs can be increased later as the need arises. - +.P Blocks in a standard LV are allocated (during creation) from the Volume Group (VG), but blocks in a thin LV are allocated (during use) from a special "thin pool LV". The thin pool LV contains blocks of physical storage, and blocks in thin LVs just reference blocks in the thin pool LV. - +.P A thin pool LV must be created before thin LVs can be created within it. A thin pool LV is created by combining two standard LVs: a large data LV that will hold blocks for thin LVs, and a metadata LV that will hold metadata. The metadata tracks which data blocks belong to each thin LV. - +.P Snapshots of thin LVs are efficient because the data blocks common to a thin LV and any of its snapshots are shared. Snapshots may be taken of thin LVs or of other thin snapshots. Blocks common to recursive snapshots are also shared in the thin pool. There is no limit to or degradation from sequences of snapshots. - +.P As thin LVs or snapshot LVs are written to, they consume data blocks in the thin pool. As free data blocks in the pool decrease, more free blocks may need to be supplied. This is done by extending the thin pool data LV @@ -36,14 +37,13 @@ snapshots from the thin pool can also free blocks in the thin pool. However, removing LVs is not always an effective way of freeing space in a thin pool because the amount is limited to the number of blocks not shared with other LVs in the pool. - +.P Incremental block allocation from thin pools can cause thin LVs to become fragmented. Standard LVs generally avoid this problem by allocating all the blocks at once during creation. - - -.SH Thin Terms - +. +.SH THIN TERMS +. .TP ThinDataLV .br @@ -52,7 +52,7 @@ thin data LV large LV created in a VG .br used by thin pool to store ThinLV blocks - +. .TP ThinMetaLV .br @@ -61,7 +61,7 @@ thin metadata LV small LV created in a VG .br used by thin pool to track data block usage - +. .TP ThinPoolLV .br @@ -70,7 +70,7 @@ thin pool LV combination of ThinDataLV and ThinMetaLV .br contains ThinLVs and SnapLVs - +. .TP ThinLV .br @@ -79,7 +79,7 @@ thin LV created from ThinPoolLV .br appears blank after creation - +. .TP SnapLV .br @@ -88,65 +88,64 @@ snapshot LV created from ThinPoolLV .br appears as a snapshot of another LV after creation - - - -.SH Thin Usage - +. +.SH THIN USAGE +. The primary method for using lvm thin provisioning: - -.SS 1. create ThinDataLV - +.nr step 1 1 +. +.SS \n[step]. Create ThinDataLV +. Create an LV that will hold thin pool data. - +.P .B lvcreate -n ThinDataLV -L LargeSize VG - +.P .I Example .br # lvcreate -n pool0 -L 10G vg - -.SS 2. create ThinMetaLV - +. +.SS \n+[step]. Create ThinMetaLV +. Create an LV that will hold thin pool metadata. - +.P .B lvcreate -n ThinMetaLV -L SmallSize VG - +.P .I Example .br # lvcreate -n pool0meta -L 1G vg - +.P # lvs LV VG Attr LSize pool0 vg -wi-a----- 10.00g pool0meta vg -wi-a----- 1.00g - -.SS 3. create ThinPoolLV - +. +.SS \n+[step]. Create ThinPoolLV +. .nf Combine the data and metadata LVs into a thin pool LV. ThinDataLV is renamed to hidden ThinPoolLV_tdata. ThinMetaLV is renamed to hidden ThinPoolLV_tmeta. The new ThinPoolLV takes the previous name of ThinDataLV. .fi - +.P .B lvconvert --type thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV - +.P .I Example .br # lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 - +.P # lvs vg/pool0 LV VG Attr LSize Pool Origin Data% Meta% pool0 vg twi-a-tz-- 10.00g 0.00 0.00 - +.P # lvs -a LV VG Attr LSize pool0 vg twi-a-tz-- 10.00g [pool0_tdata] vg Twi-ao---- 10.00g [pool0_tmeta] vg ewi-ao---- 1.00g - -.SS 4. create ThinLV - +. +.SS \n+[step]. Create ThinLV +. .nf Create a new thin LV from the thin pool LV. The thin LV is created with a virtual size. @@ -156,26 +155,26 @@ The '--type thin' option is inferred from the virtual size option. The --thinpool argument specifies which thin pool will contain the ThinLV. .fi - +.P .B lvcreate -n ThinLV -V VirtualSize --thinpool ThinPoolLV VG - +.P .I Example .br Create a thin LV in a thin pool: .br # lvcreate -n thin1 -V 1T --thinpool pool0 vg - +.P Create another thin LV in the same thin pool: .br # lvcreate -n thin2 -V 1T --thinpool pool0 vg - +.P # lvs vg/thin1 vg/thin2 LV VG Attr LSize Pool Origin Data% thin1 vg Vwi-a-tz-- 1.00t pool0 0.00 thin2 vg Vwi-a-tz-- 1.00t pool0 0.00 - -.SS 5. create SnapLV - +. +.SS \n+[step]. Create SnapLV +. Create snapshots of an existing ThinLV or SnapLV. .br Do not specify @@ -183,49 +182,49 @@ Do not specify when creating a thin snapshot. .br A size argument will cause an old COW snapshot to be created. - +.P .B lvcreate -n SnapLV --snapshot VG/ThinLV .br .B lvcreate -n SnapLV --snapshot VG/PrevSnapLV - +.P .I Example .br Create first snapshot of an existing ThinLV: .br # lvcreate -n thin1s1 -s vg/thin1 - +.P Create second snapshot of the same ThinLV: .br # lvcreate -n thin1s2 -s vg/thin1 - +.P Create a snapshot of the first snapshot: .br # lvcreate -n thin1s1s1 -s vg/thin1s1 - +.P # lvs vg/thin1s1 vg/thin1s2 vg/thin1s1s1 LV VG Attr LSize Pool Origin thin1s1 vg Vwi---tz-k 1.00t pool0 thin1 thin1s2 vg Vwi---tz-k 1.00t pool0 thin1 thin1s1s1 vg Vwi---tz-k 1.00t pool0 thin1s1 - -.SS 6. activate SnapLV - +. +.SS \n+[step]. Activate SnapLV +. Thin snapshots are created with the persistent "activation skip" flag, indicated by the "k" attribute. Use -K with lvchange or vgchange to activate thin snapshots with the "k" attribute. - +.P .B lvchange -ay -K VG/SnapLV - +.P .I Example .br # lvchange -ay -K vg/thin1s1 - +.P # lvs vg/thin1s1 LV VG Attr LSize Pool Origin thin1s1 vg Vwi-a-tz-k 1.00t pool0 thin1 - -.SH Thin Topics - +. +.SH THIN TOPICS +. .B Automatic pool metadata LV .br .B Specify devices for data and metadata LVs @@ -273,172 +272,154 @@ or vgchange to activate thin snapshots with the "k" attribute. .B Merge thin snapshots .br .B XFS on snapshots - -\& - +. .SS Automatic pool metadata LV - -\& - +. A thin data LV can be converted to a thin pool LV without specifying a thin pool metadata LV. LVM automatically creates a metadata LV from the same VG. - +.P .B lvcreate -n ThinDataLV -L LargeSize VG .br .B lvconvert --type thin-pool VG/ThinDataLV - +.P .I Example .br .nf # lvcreate -n pool0 -L 10G vg # lvconvert --type thin-pool vg/pool0 - +.P # lvs -a pool0 vg twi-a-tz-- 10.00g [pool0_tdata] vg Twi-ao---- 10.00g [pool0_tmeta] vg ewi-ao---- 16.00m .fi - - +. .SS Specify devices for data and metadata LVs - -\& - +. The data and metadata LVs in a thin pool are best created on separate physical devices. To do that, specify the device name(s) at the end of the lvcreate line. It can be especially helpful to use fast devices for the metadata LV. - +.P .B lvcreate -n ThinDataLV -L LargeSize VG LargePV .br .B lvcreate -n ThinMetaLV -L SmallSize VG SmallPV .br .B lvconvert --type thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV - +.P .I Example -.br .nf # lvcreate -n pool0 -L 10G vg /dev/sdA # lvcreate -n pool0meta -L 1G vg /dev/sdB # lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 .fi - +.P .BR lvm.conf (5) .B thin_pool_metadata_require_separate_pvs .br controls the default PV usage for thin pool creation. - -\& - +. .SS Tolerate device failures using raid - -\& - +. To tolerate device failures, use raid for the pool data LV and pool metadata LV. This is especially recommended for pool metadata LVs. - +.P .B lvcreate --type raid1 -m 1 -n ThinMetaLV -L SmallSize VG PVA PVB .br .B lvcreate --type raid1 -m 1 -n ThinDataLV -L LargeSize VG PVC PVD .br .B lvconvert --type thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV - +.P .I Example -.br .nf # lvcreate --type raid1 -m 1 -n pool0 -L 10G vg /dev/sdA /dev/sdB # lvcreate --type raid1 -m 1 -n pool0meta -L 1G vg /dev/sdC /dev/sdD # lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 .fi - - +. .SS Spare metadata LV - -\& - +. The first time a thin pool LV is created, lvm will create a spare metadata LV in the VG. This behavior can be controlled with the option --poolmetadataspare y|n. (Future thin pool creations will also attempt to create the pmspare LV if none exists.) - +.P To create the pmspare ("pool metadata spare") LV, lvm first creates an LV with a default name, e.g. lvol0, and then converts this LV to a hidden LV with the _pmspare suffix, e.g. lvol0_pmspare. - +.P One pmspare LV is kept in a VG to be used for any thin pool. - +.P The pmspare LV cannot be created explicitly, but may be removed explicitly. - +.P .I Example -.br .nf # lvcreate -n pool0 -L 10G vg # lvcreate -n pool0meta -L 1G vg # lvconvert --type thin-pool --poolmetadata vg/pool0meta vg/pool0 - +.P # lvs -a [lvol0_pmspare] vg ewi------- pool0 vg twi---tz-- [pool0_tdata] vg Twi------- [pool0_tmeta] vg ewi------- .fi - +.P The "Metadata check and repair" section describes the use of the pmspare LV. - - +. .SS Metadata check and repair - -\& - +. If thin pool metadata is damaged, it may be repairable. Checking and repairing thin pool metadata is analogous to running fsck/repair on a file system. - +.P When a thin pool LV is activated, lvm runs the thin_check command to check the correctness of the metadata on the pool metadata LV. - +.P .BR lvm.conf (5) .B thin_check_executable .br can be set to an empty string ("") to disable the thin_check step. This is not recommended. - +.P .BR lvm.conf (5) .B thin_check_options .br controls the command options used for the thin_check command. - +.P If the thin_check command finds a problem with the metadata, the thin pool LV is not activated, and the thin pool metadata needs to be repaired. - +.P Simple repair commands are not always successful. Advanced repair may require editing thin pool metadata and lvm metadata. Newer versions of the kernel and lvm tools may be more successful at repair. Report the details of damaged thin metadata to get the best advice on recovery. - +.P Command to repair a thin pool: .br .B lvconvert --repair VG/ThinPoolLV - +.P Repair performs the following steps: - -1. Creates a new, repaired copy of the metadata. +.P +.nr step 1 1 +.IP \n[step] 3 +Creates a new, repaired copy of the metadata. .br lvconvert runs the thin_repair command to read damaged metadata from the existing pool metadata LV, and writes a new repaired copy to the VG's pmspare LV. - -2. Replaces the thin pool metadata LV. +.IP \n+[step] 3 +Replaces the thin pool metadata LV. .br If step 1 is successful, the thin pool metadata LV is replaced with the pmspare LV containing the corrected metadata. The previous thin pool metadata LV, containing the damaged metadata, becomes visible with the new name ThinPoolLV_metaN (where N is 0,1,...). - +.P If the repair works, the thin pool LV and its thin LVs can be activated. User should manually check if repaired thin pool kernel metadata has all data for all lvm2 known LVs by individual activation of @@ -449,101 +430,93 @@ Once the thin pool is considered fully functional user may remove ThinPoolLV_met space reuse. For a better performance it may be useful to pvmove the new repaired metadata LV (written to previous pmspare volume) to a faster PV, e.g. SSD. - +.P If the repair operation fails, the thin pool LV and its thin LVs are not accessible and it may be necessary to restore their content from a backup. In such case the content of unmodified original damaged ThinPoolLV_metaN volume can be used by your support for more advanced recovery methods. - +.P If metadata is manually restored with thin_repair directly, the pool metadata LV can be manually swapped with another LV containing new metadata: - +.P .B lvconvert --thinpool VG/ThinPoolLV --poolmetadata VG/NewThinMetaLV - +.P Note: Thin pool metadata is compact so even small corruptions in them may result in significant portions of mappings to be lost. It is recommended to use fast resilient storage for them. - +. .SS Activation of thin snapshots - -\& - +. When a thin snapshot LV is created, it is by default given the "activation skip" flag. This flag is indicated by the "k" attribute displayed by lvs: - +.P .nf # lvs vg/thin1s1 LV VG Attr LSize Pool Origin thin1s1 vg Vwi---tz-k 1.00t pool0 thin1 .fi - +.P This flag causes the snapshot LV to be skipped, i.e. not activated, by normal activation commands. The skipping behavior does not apply to deactivation commands. - +.P A snapshot LV with the "k" attribute can be activated using the -K (or --ignoreactivationskip) option in addition to the standard -ay (or --activate y) option. - +.P Command to activate a thin snapshot LV: .br .B lvchange -ay -K VG/SnapLV - +.P The persistent "activation skip" flag can be turned off during lvcreate, or later with lvchange using the -kn (or --setactivationskip n) option. It can be turned on again with -ky (or --setactivationskip y). - +.P When the "activation skip" flag is removed, normal activation commands will activate the LV, and the -K activation option is not needed. - +.P Command to create snapshot LV without the activation skip flag: .br .B lvcreate -kn -n SnapLV -s VG/ThinLV - +.P Command to remove the activation skip flag from a snapshot LV: .br .B lvchange -kn VG/SnapLV - +.P .BR lvm.conf (5) .B auto_set_activation_skip .br controls the default activation skip setting used by lvcreate. - - +. .SS Removing thin pool LVs, thin LVs and snapshots - -\& - +. Removing a thin LV and its related snapshots returns the blocks it used to the thin pool LV. These blocks will be reused for other thin LVs and snapshots. - +.P Removing a thin pool LV removes both the data LV and metadata LV and returns the space to the VG. - +.P lvremove of thin pool LVs, thin LVs and snapshots cannot be reversed with vgcfgrestore. - +.P vgcfgbackup does not back up thin pool metadata. - - +. .SS Manually manage free data space of thin pool LV - -\& - +. The available free space in a thin pool LV can be displayed with the lvs command. Free space can be added by extending the thin pool LV. - +.P Command to extend thin pool data space: .br .B lvextend -L Size VG/ThinPoolLV - +.P .I Example .br .nf @@ -551,32 +524,29 @@ Command to extend thin pool data space: # lvs LV VG Attr LSize Pool Origin Data% pool0 vg twi-a-tz-- 10.00g 26.96 - +.P 2. Double the amount of physical space in the thin pool LV. # lvextend -L+10G vg/pool0 - +.P 3. The percentage of used data blocks is half the previous value. # lvs LV VG Attr LSize Pool Origin Data% pool0 vg twi-a-tz-- 20.00g 13.48 .fi - +.P Other methods of increasing free data space in a thin pool LV include removing a thin LV and its related snapshots, or running fstrim on the file system using a thin LV. - - +. .SS Manually manage free metadata space of a thin pool LV - -\& - +. The available metadata space in a thin pool LV can be displayed with the lvs -o+metadata_percent command. - +.P Command to extend thin pool metadata space: .br .B lvextend --poolmetadatasize Size VG/ThinPoolLV - +.P .I Example .br 1. A thin pool LV is using 12.40% of its metadata blocks. @@ -585,7 +555,7 @@ Command to extend thin pool metadata space: LV LSize Data% Meta% pool0 20.00g 13.48 12.40 .fi - +.P 2. Display a thin pool LV with its component thin data LV and thin metadata LV. .nf # lvs -a -oname,attr,size vg @@ -594,12 +564,12 @@ Command to extend thin pool metadata space: [pool0_tdata] Twi-ao---- 20.00g [pool0_tmeta] ewi-ao---- 12.00m .fi - +.P 3. Double the amount of physical space in the thin metadata LV. .nf # lvextend --poolmetadatasize +12M vg/pool0 .fi - +.P 4. The percentage of used metadata blocks is half the previous value. .nf # lvs -a -oname,size,data_percent,metadata_percent vg @@ -608,18 +578,15 @@ Command to extend thin pool metadata space: [pool0_tdata] 20.00g [pool0_tmeta] 24.00m .fi - - +. .SS Using fstrim to increase free space in a thin pool LV - -\& - +. Removing files in a file system on top of a thin LV does not generally add free space back to the thin pool. Manually running the fstrim command can return space back to the thin pool that had been used by removed files. fstrim uses discards and will not work if the thin pool LV has discards mode set to ignore. - +.P .I Example .br A thin pool has 10G of physical data space, and a thin LV has a virtual @@ -628,166 +595,157 @@ free space in the thin pool by 10% and increases the virtual usage of the file system by 1%. Removing the 1G file restores the virtual 1% to the file system, but does not restore the physical 10% to the thin pool. The fstrim command restores the physical space to the thin pool. - +.P .nf # lvs -a -oname,attr,size,pool_lv,origin,data_percent,metadata_percent vg -LV Attr LSize Pool Origin Data% Meta% -pool0 twi-a-tz-- 10.00g 47.01 21.03 -thin1 Vwi-aotz-- 100.00g pool0 2.70 - + LV Attr LSize Pool Origin Data% Meta% + pool0 twi-a-tz-- 10.00g 47.01 21.03 + thin1 Vwi-aotz-- 100.00g pool0 2.70 +.P # df -h /mnt/X Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-thin1 99G 1.1G 93G 2% /mnt/X - +.P # dd if=/dev/zero of=/mnt/X/1Gfile bs=4096 count=262144; sync - +.P # lvs -pool0 vg twi-a-tz-- 10.00g 57.01 25.26 -thin1 vg Vwi-aotz-- 100.00g pool0 3.70 - + pool0 vg twi-a-tz-- 10.00g 57.01 25.26 + thin1 vg Vwi-aotz-- 100.00g pool0 3.70 +.P # df -h /mnt/X /dev/mapper/vg-thin1 99G 2.1G 92G 3% /mnt/X - +.P # rm /mnt/X/1Gfile - +.P # lvs -pool0 vg twi-a-tz-- 10.00g 57.01 25.26 -thin1 vg Vwi-aotz-- 100.00g pool0 3.70 - + pool0 vg twi-a-tz-- 10.00g 57.01 25.26 + thin1 vg Vwi-aotz-- 100.00g pool0 3.70 +.P # df -h /mnt/X /dev/mapper/vg-thin1 99G 1.1G 93G 2% /mnt/X - +.P # fstrim -v /mnt/X - +.P # lvs -pool0 vg twi-a-tz-- 10.00g 47.01 21.03 -thin1 vg Vwi-aotz-- 100.00g pool0 2.70 + pool0 vg twi-a-tz-- 10.00g 47.01 21.03 + thin1 vg Vwi-aotz-- 100.00g pool0 2.70 .fi - +.P The "Discard" section covers an option for automatically freeing data space in a thin pool. - - +. .SS Automatically extend thin pool LV - -\& - +. The lvm daemon dmeventd (lvm2-monitor) monitors the data usage of thin pool LVs and extends them when the usage reaches a certain level. The necessary free space must exist in the VG to extend thin pool LVs. Monitoring and extension of thin pool LVs are controlled independently. - -.I monitoring - +.P +\(em Monitoring \(em +.P When a thin pool LV is activated, dmeventd will begin monitoring it by default. - +.sp Command to start or stop dmeventd monitoring a thin pool LV: .br -.B lvchange --monitor {y|n} VG/ThinPoolLV - +.B lvchange --monitor y|n VG/ThinPoolLV +.sp The current dmeventd monitoring status of a thin pool LV can be displayed with the command lvs -o+seg_monitor. - -.I autoextend - +.P +\(em Autoextending \(em +.P dmeventd should be configured to extend thin pool LVs before all data space is used. Warnings are emitted through syslog when the use of a thin pool reaches 80%, 85%, 90% and 95%. (See the section "Data space exhaustion" for the effects of not extending a thin pool LV.) The point at which dmeventd extends thin pool LVs, and the amount are controlled with two configuration settings: - +.P .BR lvm.conf (5) .B thin_pool_autoextend_threshold .br is a percentage full value that defines when the thin pool LV should be extended. Setting this to 100 disables automatic extension. The minimum value is 50. - +.P .BR lvm.conf (5) .B thin_pool_autoextend_percent .br defines how much extra data space should be added to the thin pool LV from the VG, in percent of its current size. - -.I disabling - +.P +\(em Disabling \(em +.P There are multiple ways that extension of thin pools could be prevented: - .IP \[bu] 2 If the dmeventd daemon is not running, no monitoring or automatic extension will occur. - +. .IP \[bu] Even when dmeventd is running, all monitoring can be disabled with the lvm.conf monitoring setting. - +. .IP \[bu] To activate or create a thin pool LV without interacting with dmeventd, the --ignoremonitoring option can be used. With this option, the command will not ask dmeventd to monitor the thin pool LV. - +. .IP \[bu] Setting thin_pool_autoextend_threshold to 100 disables automatic extension of thin pool LVs, even if they are being monitored by dmeventd. - .P - .I Example .br If thin_pool_autoextend_threshold is 70 and thin_pool_autoextend_percent is 20, whenever a pool exceeds 70% usage, it will be extended by another 20%. For a 1G pool, using 700M will trigger a resize to 1.2G. When the usage exceeds 840M, the pool will be extended to 1.44G, and so on. - - +. .SS Data space exhaustion - -\& - +. When properly managed, thin pool data space should be extended before it is all used (see the section "Automatically extend thin pool LV"). If thin pool data space is already exhausted, it can still be extended (see the section "Manually manage free data space of thin pool LV".) - +.P The behavior of a full thin pool is configurable with the --errorwhenfull y|n option to lvcreate or lvchange. The errorwhenfull setting applies only to writes; reading thin LVs can continue even when data space is exhausted. - +.P Command to change the handling of a full thin pool: .br -.B lvchange --errorwhenfull {y|n} VG/ThinPoolLV - +.B lvchange --errorwhenfull y|n VG/ThinPoolLV +.P .BR lvm.conf (5) .B error_when_full .br controls the default error when full behavior. - +.P The current setting of a thin pool LV can be displayed with the command: lvs -o+lv_when_full. - +.P The errorwhenfull setting does not effect the monitoring and autoextend settings, and the monitoring/autoextend settings do not effect the errorwhenfull setting. It is only when monitoring/autoextend are not effective that the thin pool becomes full and the errorwhenfull setting is applied. - -.I errorwhenfull n - +.P +\(em errorwhenfull n \(em +.P This is the default. Writes to thin LVs are accepted and queued, with the expectation that pool data space will be extended soon. Once data space is extended, the queued writes will be processed, and the thin pool will return to normal operation. - +.P While waiting to be extended, the thin pool will queue writes for up to 60 seconds (the default). If data space has not been extended after this time, the queued writes will return an error to the caller, e.g. the file system. This can result in file system corruption for non-journaled file systems that may require repair. When a thin pool returns errors for writes to a thin LV, any file system is subject to losing unsynced user data. - +.P The 60 second timeout can be changed or disabled with the dm-thin-pool kernel module option .B no_space_timeout. @@ -795,330 +753,315 @@ This option sets the number of seconds that thin pools will queue writes. If set to 0, writes will not time out. Disabling timeouts can result in the system running out of resources, memory exhaustion, hung tasks, and deadlocks. (The timeout applies to all thin pools on the system.) - -.I errorwhenfull y - +.P +\(em errorwhenfull y \(em +.P Writes to thin LVs immediately return an error, and no writes are queued. In the case of a file system, this can result in corruption that may require fs repair (the specific consequences depend on the thin LV user.) - -.I data percent - +.P +\(em data percent \(em +.P When data space is exhausted, the lvs command displays 100 under Data% for the thin pool LV: - +.P .nf # lvs vg/pool0 LV VG Attr LSize Pool Origin Data% pool0 vg twi-a-tz-- 512.00m 100.00 .fi - -.I causes - +.P +\(em causes \(em +.P A thin pool may run out of data space for any of the following reasons: - +. .IP \[bu] 2 Automatic extension of the thin pool is disabled, and the thin pool is not manually extended. (Disabling automatic extension is not recommended.) - +. .IP \[bu] The dmeventd daemon is not running and the thin pool is not manually extended. (Disabling dmeventd is not recommended.) - +. .IP \[bu] Automatic extension of the thin pool is too slow given the rate of writes to thin LVs in the pool. (This can be addressed by tuning the thin_pool_autoextend_threshold and thin_pool_autoextend_percent. See "Automatic extend settings".) - +. .IP \[bu] The VG does not have enough free blocks to extend the thin pool. - -.P - +. .SS Metadata space exhaustion - -\& - +. If thin pool metadata space is exhausted (or a thin pool metadata operation fails), errors will be returned for IO operations on thin LVs. - +.P When metadata space is exhausted, the lvs command displays 100 under Meta% for the thin pool LV: - +.P .nf # lvs -o lv_name,size,data_percent,metadata_percent vg/pool0 LV LSize Data% Meta% pool0 100.00 .fi - +.P The same reasons for thin pool data space exhaustion apply to thin pool metadata space. - +.P Metadata space exhaustion can lead to inconsistent thin pool metadata and inconsistent file systems, so the response requires offline checking and repair. - -1. Deactivate the thin pool LV, or reboot the system if this is not possible. - -2. Repair thin pool with lvconvert --repair. -.br - See "Metadata check and repair". - -3. Extend pool metadata space with lvextend --poolmetadatasize. -.br - See "Manually manage free metadata space of a thin pool LV". - -4. Check and repair file system. - - +.TP 4 +1. +Deactivate the thin pool LV, or reboot the system if this is not possible. +.TP +2. +Repair thin pool with lvconvert --repair. +.br +See "Metadata check and repair". +.TP +3. +Extend pool metadata space with lvextend --poolmetadatasize. +.br +See "Manually manage free metadata space of a thin pool LV". +.TP +4. +Check and repair file system. +. .SS Automatic extend settings - -\& - +. Thin pool LVs can be extended according to preset values. The presets determine if the LV should be extended based on how full it is, and if so by how much. When dmeventd monitors thin pool LVs, it uses lvextend with these presets. (See "Automatically extend thin pool LV".) - +.P Command to extend a thin pool data LV using presets: .br .B lvextend --use-policies VG/ThinPoolLV - +.P The command uses these settings: - +.P .BR lvm.conf (5) .B thin_pool_autoextend_threshold .br autoextend the LV when its usage exceeds this percent. - +.P .BR lvm.conf (5) .B thin_pool_autoextend_percent .br autoextend the LV by this much additional space. - +.P To see the default values of these settings, run: - +.P .B lvmconfig --type default --withcomment .RS .B activation/thin_pool_autoextend_threshold .RE - +.P .B lvmconfig --type default --withcomment .RS .B activation/thin_pool_autoextend_percent .RE - +.P To change these values globally, edit .BR lvm.conf (5). - +.P To change these values on a per-VG or per-LV basis, attach a "profile" to the VG or LV. A profile is a collection of config settings, saved in a local text file (using the lvm.conf format). lvm looks for profiles in the profile_dir directory, e.g. #DEFAULT_SYS_DIR#/profile/. Once attached to a VG or LV, lvm will process the VG or LV using the settings from the attached profile. A profile is named and referenced by its file name. - +.P To use a profile to customize the lvextend settings for an LV: - +. .IP \[bu] 2 Create a file containing settings, saved in profile_dir. +.br For the profile_dir location, run: .br .B lvmconfig config/profile_dir - -.IP \[bu] 2 +. +.IP \[bu] Attach the profile to an LV, using the command: .br .B lvchange --metadataprofile ProfileName VG/ThinPoolLV - -.IP \[bu] 2 +. +.IP \[bu] Extend the LV using the profile settings: .br .B lvextend --use-policies VG/ThinPoolLV - .P - .I Example .br .nf # lvmconfig config/profile_dir profile_dir="#DEFAULT_SYS_DIR#/profile" - +.P # cat #DEFAULT_SYS_DIR#/profile/pool0extend.profile activation { thin_pool_autoextend_threshold=50 thin_pool_autoextend_percent=10 } - +.P # lvchange --metadataprofile pool0extend vg/pool0 - +.P # lvextend --use-policies vg/pool0 .fi - -.I Notes +.P +Notes +. .IP \[bu] 2 A profile is attached to a VG or LV by name, where the name references a local file in profile_dir. If the VG is moved to another machine, the file with the profile also needs to be moved. - -.IP \[bu] 2 +. +.IP \[bu] Only certain settings can be used in a VG or LV profile, see: .br .B lvmconfig --type profilable-metadata. - -.IP \[bu] 2 +. +.IP \[bu] An LV without a profile of its own will inherit the VG profile. - -.IP \[bu] 2 +. +.IP \[bu] Remove a profile from an LV using the command: .br .B lvchange --detachprofile VG/ThinPoolLV. - -.IP \[bu] 2 +. +.IP \[bu] Commands can also have profiles applied to them. The settings that can be applied to a command are different than the settings that can be applied to a VG or LV. See lvmconfig --type profilable-command. To apply a profile to a command, write a profile, save it in the profile directory, and run the command using the option: --commandprofile ProfileName. - - +. .SS Zeroing - -\& - +. When a thin pool provisions a new data block for a thin LV, the new block is first overwritten with zeros. The zeroing mode is indicated by the "z" attribute displayed by lvs. The option -Z (or --zero) can be added to commands to specify the zeroing mode. - +.P Command to set the zeroing mode when creating a thin pool LV: -.br -.B lvconvert --type thin-pool -Z{y|n} -.br +.P +.B lvconvert --type thin-pool -Z y|n .RS .B --poolmetadata VG/ThinMetaLV VG/ThinDataLV .RE - +.P Command to change the zeroing mode of an existing thin pool LV: -.br -.B lvchange -Z{y|n} VG/ThinPoolLV - +.P +.B lvchange -Z y|n VG/ThinPoolLV +.P If zeroing mode is changed from "n" to "y", previously provisioned blocks are not zeroed. - +.P Provisioning of large zeroed chunks impacts performance. - +.P .BR lvm.conf (5) .B thin_pool_zero .br controls the default zeroing mode used when creating a thin pool. - - +. .SS Discard - -\& - +. The discard behavior of a thin pool LV determines how discard requests are handled. Enabling discard under a file system may adversely affect the file system performance (see the section on fstrim for an alternative.) Possible discard behaviors: - -ignore: Ignore any discards that are received. - -nopassdown: Process any discards in the thin pool itself and allow +.P +.B ignore: +Ignore any discards that are received. +.P +.B nopassdown: +Process any discards in the thin pool itself and allow the no longer needed extents to be overwritten by new data. - -passdown: Process discards in the thin pool (as with nopassdown), and +.P +.B passdown: +Process discards in the thin pool (as with nopassdown), and pass the discards down the the underlying device. This is the default mode. - +.P Command to display the current discard mode of a thin pool LV: .br .B lvs -o+discards VG/ThinPoolLV - +.P Command to set the discard mode when creating a thin pool LV: .br -.B lvconvert --discards {ignore|nopassdown|passdown} -.br +.B lvconvert --discards ignore|nopassdown|passdown .RS .B --type thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV .RE - +.P Command to change the discard mode of an existing thin pool LV: .br -.B lvchange --discards {ignore|nopassdown|passdown} VG/ThinPoolLV - +.B lvchange --discards ignore|nopassdown|passdown VG/ThinPoolLV +.P .I Example -.br .nf # lvs -o name,discards vg/pool0 -pool0 passdown - + pool0 passdown +.P # lvchange --discards ignore vg/pool0 .fi - +.P .BR lvm.conf (5) .B thin_pool_discards .br controls the default discards mode used when creating a thin pool. - - +. .SS Chunk size - -\& - +. The size of data blocks managed by a thin pool can be specified with the --chunksize option when the thin pool LV is created. The default unit is KiB. The value must be a multiple of 64KiB between 64KiB and 1GiB. - +.P When a thin pool is used primarily for the thin provisioning feature, a larger value is optimal. To optimize for many snapshots, a smaller value reduces copying time and consumes less space. - +.P Command to display the thin pool LV chunk size: -.br +.P .B lvs -o+chunksize VG/ThinPoolLV - +.P .I Example -.br .nf # lvs -o name,chunksize pool0 64.00k .fi - +.P .BR lvm.conf (5) .B thin_pool_chunk_size .br controls the default chunk size used when creating a thin pool. - +.P The default value is shown by: .br .B lvmconfig --type default allocation/thin_pool_chunk_size - - +.P +. .SS Size of pool metadata LV - -\& - +. The amount of thin metadata depends on how many blocks are shared between thin LVs (i.e. through snapshots). A thin pool with many snapshots may need a larger metadata LV. Thin pool metadata LV sizes can be from 2MiB to approximately 16GiB. - +.P When using lvcreate to create what will become a thin metadata LV, the size is specified with the -L|--size option. - +.P When an LVM command automatically creates a thin metadata LV, the size is specified with the --poolmetadatasize option. When this option is not given, LVM automatically chooses a size based on the data size and chunk size. - +.P It can be hard to predict the amount of metadata space that will be needed, so it is recommended to start with a size of 1GiB which should be enough for all practical purposes. A thin pool metadata LV can later be manually or automatically extended if needed. - +.P Configurable setting .BR lvm.conf (5) .BR allocation / thin_pool_crop_metadata @@ -1126,38 +1069,31 @@ gives control over cropping to 15.81GiB to stay backward compatible with older versions of lvm2. With enabled cropping there can be observed some problems when using volumes above this size with thin tools (i.e. thin_repair). Cropping should be enabled only when compatibility is required. - - +. .SS Create a thin snapshot of an external, read only LV - -\& - +. Thin snapshots are typically taken of other thin LVs or other thin snapshot LVs within the same thin pool. It is also possible to take thin snapshots of external, read only LVs. Writes to the snapshot are stored in the thin pool, and the external LV is used to read unwritten parts of the thin snapshot. - +.P .B lvcreate -n SnapLV -s VG/ExternalOriginLV --thinpool VG/ThinPoolLV - +.P .I Example -.br .nf # lvchange -an vg/lve # lvchange --permission r vg/lve # lvcreate -n snaplve -s vg/lve --thinpool vg/pool0 - +.P # lvs vg/lve vg/snaplve LV VG Attr LSize Pool Origin Data% lve vg ori------- 10.00g snaplve vg Vwi-a-tz-- 10.00g pool0 lve 0.00 .fi - - +. .SS Convert a standard LV to a thin LV with an external origin - -\& - +. A new thin LV can be created and given the name of an existing standard LV. At the same time, the existing LV is converted to a read only external LV with a new name. Unwritten portions of the @@ -1165,66 +1101,57 @@ thin LV are read from the external LV. The new name given to the existing LV can be specified with --originname, otherwise the existing LV will be given a default name, e.g. lvol#. - +.P Convert ExampleLV into a read only external LV with the new name NewExternalOriginLV, and create a new thin LV that is given the previous name of ExampleLV. - +.P .B lvconvert --type thin --thinpool VG/ThinPoolLV -.br .RS .B --originname NewExternalOriginLV VG/ExampleLV .RE - +.P .I Example -.br .nf # lvcreate -n lv_example -L 10G vg - +.P # lvs lv_example vg -wi-a----- 10.00g - +.P # lvconvert --type thin --thinpool vg/pool0 --originname lv_external --thin vg/lv_example - +.P # lvs LV VG Attr LSize Pool Origin lv_example vg Vwi-a-tz-- 10.00g pool0 lv_external lv_external vg ori------- 10.00g .fi - - +. .SS Single step thin pool LV creation - -\& - +. A thin pool LV can be created with a single lvcreate command, rather than using lvconvert on existing LVs. This one command creates a thin data LV, a thin metadata LV, and combines the two into a thin pool LV. - +.P .B lvcreate --type thin-pool -L LargeSize -n ThinPoolLV VG - +.P .I Example -.br .nf # lvcreate --type thin-pool -L8M -n pool0 vg - +.P # lvs vg/pool0 LV VG Attr LSize Pool Origin Data% pool0 vg twi-a-tz-- 8.00m 0.00 - +.P # lvs -a pool0 vg twi-a-tz-- 8.00m [pool0_tdata] vg Twi-ao---- 8.00m [pool0_tmeta] vg ewi-ao---- 8.00m .fi - - +. .SS Single step thin pool LV and thin LV creation - -\& - +. A thin pool LV and a thin LV can be created with a single lvcreate command. This one command creates a thin data LV, a thin metadata LV, combines the two into a thin pool LV, @@ -1233,92 +1160,86 @@ and creates a thin LV in the new pool. -L LargeSize specifies the physical size of the thin pool LV. .br -V VirtualSize specifies the virtual size of the thin LV. - +.P .B lvcreate --type thin -V VirtualSize -L LargeSize .RS .B -n ThinLV --thinpool VG/ThinPoolLV .RE - +.P Equivalent to: .br .B lvcreate --type thin-pool -L LargeSize VG/ThinPoolLV .br .B lvcreate -n ThinLV -V VirtualSize --thinpool VG/ThinPoolLV - +.P .I Example -.br .nf # lvcreate -L8M -V2G -n thin1 --thinpool vg/pool0 - +.P # lvs -a pool0 vg twi-a-tz-- 8.00m [pool0_tdata] vg Twi-ao---- 8.00m [pool0_tmeta] vg ewi-ao---- 8.00m thin1 vg Vwi-a-tz-- 2.00g pool0 .fi - - +. .SS Merge thin snapshots - -\& - +. A thin snapshot can be merged into its origin thin LV using the lvconvert --merge command. The result of a snapshot merge is that the origin thin LV takes the content of the snapshot LV, and the snapshot LV is removed. Any content that was unique to the origin thin LV is lost after the merge. - +.P Because a merge changes the content of an LV, it cannot be done while the LVs are open, e.g. mounted. If a merge is initiated while the LVs are open, the effect of the merge is delayed until the origin thin LV is next activated. - +.P .B lvconvert --merge VG/SnapLV - +.P .I Example -.br .nf # lvs vg LV VG Attr LSize Pool Origin pool0 vg twi-a-tz-- 10.00g thin1 vg Vwi-a-tz-- 100.00g pool0 thin1s1 vg Vwi-a-tz-k 100.00g pool0 thin1 - +.P # lvconvert --merge vg/thin1s1 - +.P # lvs vg LV VG Attr LSize Pool Origin pool0 vg twi-a-tz-- 10.00g thin1 vg Vwi-a-tz-- 100.00g pool0 .fi - +.P .I Example -.br .nf Delayed merging of open LVs. - +.P # lvs vg LV VG Attr LSize Pool Origin pool0 vg twi-a-tz-- 10.00g thin1 vg Vwi-aotz-- 100.00g pool0 thin1s1 vg Vwi-aotz-k 100.00g pool0 thin1 - +.P # df /dev/mapper/vg-thin1 100G 33M 100G 1% /mnt/X /dev/mapper/vg-thin1s1 100G 33M 100G 1% /mnt/Xs - +.P # ls /mnt/X file1 file2 file3 # ls /mnt/Xs file3 file4 file5 - +.P # lvconvert --merge vg/thin1s1 Logical volume vg/thin1s1 contains a filesystem in use. Delaying merge since snapshot is open. Merging of thin snapshot thin1s1 will occur on next activation. - +.P # umount /mnt/X # umount /mnt/Xs - +.P # lvs -a vg LV VG Attr LSize Pool Origin pool0 vg twi-a-tz-- 10.00g @@ -1326,47 +1247,47 @@ Merging of thin snapshot thin1s1 will occur on next activation. [pool0_tmeta] vg ewi-ao---- 1.00g thin1 vg Owi-a-tz-- 100.00g pool0 [thin1s1] vg Swi-a-tz-k 100.00g pool0 thin1 - +.P # lvchange -an vg/thin1 # lvchange -ay vg/thin1 - +.P # mount /dev/vg/thin1 /mnt/X - +.P # ls /mnt/X file3 file4 file5 .fi - - +. .SS XFS on snapshots - -\& - +. Mounting an XFS file system on a new snapshot LV requires attention to the file system's log state and uuid. On the snapshot LV, the xfs log will contain a dummy transaction, and the xfs uuid will match the uuid from the file system on the origin LV. - +.P If the snapshot LV is writable, mounting will recover the log to clear the dummy transaction, but will require skipping the uuid check: - -mount /dev/VG/SnapLV /mnt -o nouuid - +.P +# mount /dev/VG/SnapLV /mnt -o nouuid +.P After the first mount with the above approach, the UUID can subsequently be changed using: - -xfs_admin -U generate /dev/VG/SnapLV -.br -mount /dev/VG/SnapLV /mnt - +.P +# xfs_admin -U generate /dev/VG/SnapLV +.P +# mount /dev/VG/SnapLV /mnt +.P Once the UUID has been changed, the mount command will no longer require the nouuid option. - +.P If the snapshot LV is readonly, the log recovery and uuid check need to be skipped while mounting readonly: - -mount /dev/VG/SnapLV /mnt -o ro,nouuid,norecovery - +.P +# mount /dev/VG/SnapLV /mnt -o ro,nouuid,norecovery +. .SH SEE ALSO +. +.nh +.ad l .BR lvm (8), .BR lvm.conf (5), .BR lvmconfig (8), @@ -1376,7 +1297,7 @@ mount /dev/VG/SnapLV /mnt -o ro,nouuid,norecovery .BR lvextend (8), .BR lvremove (8), .BR lvs (8), +.P .BR thin_dump (8), -.BR thin_repair (8) +.BR thin_repair (8), .BR thin_restore (8) - diff --git a/man/lvmvdo.7_main b/man/lvmvdo.7_main index 55b9fa2a6..7bc27b189 100644 --- a/man/lvmvdo.7_main +++ b/man/lvmvdo.7_main @@ -1,19 +1,22 @@ .TH "LVMVDO" "7" "LVM TOOLS #VERSION#" "Red Hat, Inc" "\"" - +. .SH NAME +. lvmvdo \(em Support for Virtual Data Optimizer in LVM +. .SH DESCRIPTION +. VDO is software that provides inline block-level deduplication, compression, and thin provisioning capabilities for primary storage. - +.P Deduplication is a technique for reducing the consumption of storage resources by eliminating multiple copies of duplicate blocks. Compression takes the individual unique blocks and shrinks them. These reduced blocks are then efficiently packed together into physical blocks. Thin provisioning manages the mapping from logical blocks presented by VDO to where the data has actually been physically stored, and also eliminates any blocks of all zeroes. - +.P With deduplication, instead of writing the same data more than once, VDO detects and records each duplicate block as a reference to the original block. VDO maintains a mapping from Logical Block Addresses (LBA) (used by the @@ -21,31 +24,33 @@ storage layer above VDO) to physical block addresses (used by the storage layer under VDO). After deduplication, multiple logical block addresses may be mapped to the same physical block address; these are called shared blocks and are reference-counted by the software. - +.P With compression, VDO compresses multiple blocks (or shared blocks) with the fast LZ4 algorithm, and bins them together where possible so that multiple compressed blocks fit within a 4 KB block on the underlying storage. Mapping from LBA is to a physical block address and index within it for the desired compressed data. All compressed blocks are individually reference counted for correctness. - +.P Block sharing and block compression are invisible to applications using the storage, which read and write blocks as they would if VDO were not present. When a shared block is overwritten, a new physical block is allocated for storing the new block data to ensure that other logical block addresses that are mapped to the shared physical block are not modified. - +.P To use VDO with \fBlvm\fP(8), you must install the standard VDO user-space tools \fBvdoformat\fP(8) and the currently non-standard kernel VDO module "\fIkvdo\fP". - +.P The "\fIkvdo\fP" module implements fine-grained storage virtualization, thin provisioning, block sharing, and compression. The "\fIuds\fP" module provides memory-efficient duplicate identification. The user-space tools include \fBvdostats\fP(8) for extracting statistics from VDO volumes. +. .SH VDO TERMS +. .TP VDODataLV .br @@ -54,6 +59,7 @@ VDO data LV A large hidden LV with the _vdata suffix. It is created in a VG .br used by the VDO kernel target to store all data and metadata blocks. +. .TP VDOPoolLV .br @@ -62,6 +68,7 @@ VDO pool LV A pool for virtual VDOLV(s), which are the size of used VDODataLV. .br Only a single VDOLV is currently supported. +. .TP VDOLV .br @@ -70,9 +77,14 @@ VDO LV Created from VDOPoolLV. .br Appears blank after creation. +. .SH VDO USAGE +. The primary methods for using VDO with lvm2: -.SS 1. Create a VDOPoolLV and a VDOLV +.nr step 1 1 +. +.SS \n[step]. Create a VDOPoolLV and a VDOLV +. Create a VDOPoolLV that will hold VDO data, and a virtual size VDOLV that the user can use. If you do not specify the virtual size, then the VDOLV is created with the maximum size that @@ -81,23 +93,25 @@ deduplication or compression can happen (i.e. it can hold the incompressible content of /dev/urandom). If you do not specify the name of VDOPoolLV, it is taken from the sequence of vpool0, vpool1 ... - +.P Note: The performance of TRIM/Discard operations is slow for large volumes of VDO type. Please try to avoid sending discard requests unless necessary because it might take considerable amount of time to finish the discard operation. - +.P .nf .B lvcreate --type vdo -n VDOLV -L DataSize -V LargeVirtualSize VG/VDOPoolLV .B lvcreate --vdo -L DataSize VG .fi - +.P .I Example .nf # lvcreate --type vdo -n vdo0 -L 10G -V 100G vg/vdopool0 # mkfs.ext4 -E nodiscard /dev/vg/vdo0 .fi -.SS 2. Convert an existing LV into VDOPoolLV +. +.SS \n+[step]. Convert an existing LV into VDOPoolLV +. Convert an already created or existing LV into a VDOPoolLV, which is a volume that can hold data and metadata. You will be prompted to confirm such conversion because it \fBIRREVERSIBLY @@ -106,24 +120,26 @@ formatted by \fBvdoformat\fP(8) as a VDO pool data volume. You can specify the virtual size of the VDOLV associated with this VDOPoolLV. If you do not specify the virtual size, it will be set to the maximum size that can keep 100% incompressible data there. - +.P .nf .B lvconvert --type vdo-pool -n VDOLV -V VirtualSize VG/VDOPoolLV .B lvconvert --vdopool VG/VDOPoolLV .fi - +.P .I Example .nf # lvconvert --type vdo-pool -n vdo0 -V10G vg/ExistingLV .fi -.SS 3. Change the default settings used for creating a VDOPoolLV +. +.SS \n+[step]. Change the default settings used for creating a VDOPoolLV +. VDO allows to set a large variety of options. Lots of these settings can be specified in lvm.conf or profile settings. You can prepare a number of different profiles in the #DEFAULT_SYS_DIR#/profile directory and just specify the profile file name. Check the output of \fBlvmconfig --type default --withcomments\fP for a detailed description of all individual VDO settings. - +.P .I Example .nf # cat <<EOF > #DEFAULT_SYS_DIR#/profile/vdo_create.profile @@ -149,43 +165,45 @@ allocation { vdo_max_discard=1 } EOF - +.P # lvcreate --vdo -L10G --metadataprofile vdo_create vg/vdopool0 # lvcreate --vdo -L10G --config 'allocation/vdo_cpu_threads=4' vg/vdopool1 .fi -.SS 4. Change the compression and deduplication of a VDOPoolLV +. +.SS \n+[step]. Change the compression and deduplication of a VDOPoolLV +. Disable or enable the compression and deduplication for VDOPoolLV (the volume that maintains all VDO LV(s) associated with it). - -.nf +.P .B lvchange --compression [y|n] --deduplication [y|n] VG/VDOPoolLV -.fi - +.P .I Example .nf # lvchange --compression n vg/vdopool0 # lvchange --deduplication y vg/vdopool1 .fi -.SS 5. Checking the usage of VDOPoolLV +. +.SS \n+[step]. Checking the usage of VDOPoolLV +. To quickly check how much data on a VDOPoolLV is already consumed, use \fBlvs\fP(8). The Data% field reports how much data is occupied in the content of the virtual data for the VDOLV and how much space is already consumed with all the data and metadata blocks in the VDOPoolLV. For a detailed description, use the \fBvdostats\fP(8) command. - +.P Note: \fBvdostats\fP(8) currently understands only /dev/mapper device names. - +.P .I Example .nf # lvcreate --type vdo -L10G -V20G -n vdo0 vg/vdopool0 # mkfs.ext4 -E nodiscard /dev/vg/vdo0 # lvs -a vg - +.P LV VG Attr LSize Pool Origin Data% vdo0 vg vwi-a-v--- 20.00g vdopool0 0.01 vdopool0 vg dwi-ao---- 10.00g 30.16 [vdopool0_vdata] vg Dwi-ao---- 10.00g - +.P # vdostats --all /dev/mapper/vg-vdopool0-vpool /dev/mapper/vg-vdopool0 : version : 30 @@ -193,76 +211,88 @@ Note: \fBvdostats\fP(8) currently understands only /dev/mapper device names. data blocks used : 79 ... .fi -.SS 6. Extending the VDOPoolLV size +. +.SS \n+[step]. Extending the VDOPoolLV size +. You can add more space to hold VDO data and metadata by extending the VDODataLV using the commands \fBlvresize\fP(8) and \fBlvextend\fP(8). The extension needs to add at least one new VDO slab. You can configure the slab size with the \fBallocation/vdo_slab_size_mb\fP setting. - +.P You can also enable automatic size extension of a monitored VDOPoolLV with the \fBactivation/vdo_pool_autoextend_percent\fP and \fBactivation/vdo_pool_autoextend_threshold\fP settings. - +.P Note: You cannot reduce the size of a VDOPoolLV. - -.nf +.P .B lvextend -L+AddingSize VG/VDOPoolLV -.fi - +.P .I Example .nf # lvextend -L+50G vg/vdopool0 # lvresize -L300G vg/vdopool1 .fi -.SS 7. Extending or reducing the VDOLV size +. +.SS \n+[step]. Extending or reducing the VDOLV size +. You can extend or reduce a virtual VDO LV as a standard LV with the \fBlvresize\fP(8), \fBlvextend\fP(8), and \fBlvreduce\fP(8) commands. - +.P Note: The reduction needs to process TRIM for reduced disk area to unmap used data blocks from the VDOPoolLV, which might take a long time. - -.nf +.P .B lvextend -L+AddingSize VG/VDOLV +.br .B lvreduce -L-ReducingSize VG/VDOLV -.fi - +.P .I Example .nf # lvextend -L+50G vg/vdo0 # lvreduce -L-50G vg/vdo1 # lvresize -L200G vg/vdo2 .fi -.SS 8. Component activation of a VDODataLV +. +.SS \n+[step]. Component activation of a VDODataLV +. You can activate a VDODataLV separately as a component LV for examination purposes. The activation of the VDODataLV activates the data LV in read-only mode, and the data LV cannot be modified. If the VDODataLV is active as a component, any upper LV using this volume CANNOT be activated. You have to deactivate the VDODataLV first to continue to use the VDOPoolLV. - +.P .I Example .nf # lvchange -ay vg/vpool0_vdata # lvchange -an vg/vpool0_vdata .fi +. .SH VDO TOPICS -.SS 1. Stacking VDO +. +.nr step 1 1 +. +.SS \n[step]. Stacking VDO +. You can convert or stack a VDOPooLV with these currently supported volume types: linear, stripe, raid, and cache with cachepool. -.SS 2. VDOPoolLV on top of raid +. +.SS \n+[step]. VDOPoolLV on top of raid +. Using a raid type LV for a VDODataLV. - +.P .I Example .nf # lvcreate --type raid1 -L 5G -n vdopool vg # lvconvert --type vdo-pool -V 10G vg/vdopool .fi -.SS 3. Caching a VDODataLV or a VDOPoolLV +. +.SS \n+[step]. Caching a VDODataLV or a VDOPoolLV +. VDODataLV (accepts also VDOPoolLV) caching provides a mechanism to accelerate reads and writes of already compressed and deduplicated data blocks together with VDO metadata. - +.P .I Example .nf # lvcreate --type vdo -L 5G -V 10G -n vdo1 vg/vdopool @@ -270,10 +300,12 @@ data blocks together with VDO metadata. # lvconvert --cache --cachepool vg/cachepool vg/vdopool # lvconvert --uncache vg/vdopool .fi -.SS 4. Caching a VDOLV +. +.SS \n+[step]. Caching a VDOLV +. VDO LV cache allow you to 'cache' a device for better performance before it hits the processing of the VDO Pool LV layer. - +.P .I Example .nf # lvcreate --type vdo -L 5G -V 10G -n vdo1 vg/vdopool @@ -281,12 +313,14 @@ it hits the processing of the VDO Pool LV layer. # lvconvert --cache --cachepool vg/cachepool vg/vdo1 # lvconvert --uncache vg/vdo1 .fi -.SS 5. Usage of Discard/TRIM with a VDOLV +. +.SS \n+[step]. Usage of Discard/TRIM with a VDOLV +. You can discard data on a VDO LV and reduce used blocks on a VDOPoolLV. However, the current performance of discard operations is still not optimal and takes a considerable amount of time and CPU. Unless you really need it, you should avoid using discard. - +.P When a block device is going to be rewritten, its blocks will be automatically reused for new data. Discard is useful in situations when user knows that the given portion of a VDO LV @@ -295,55 +329,59 @@ provisioning in other regions of the VDO LV. For the same reason, you should avoid using mkfs with discard for a freshly created VDO LV to save a lot of time that this operation would take otherwise as device is already expected to be empty. -.SS 6. Memory usage +. +.SS \n+[step]. Memory usage +. The VDO target requires 370 MiB of RAM plus an additional 268 MiB per each 1 TiB of physical storage managed by the volume. - +.P UDS requires a minimum of 250 MiB of RAM, which is also the default amount that deduplication uses. - +.P The memory required for the UDS index is determined by the index type and the required size of the deduplication window and is controlled by the \fBallocation/vdo_use_sparse_index\fP setting. - +.P With enabled UDS sparse indexing, it relies on the temporal locality of data and attempts to retain only the most relevant index entries in memory and can maintain a deduplication window that is ten times larger than with dense while using the same amount of memory. - +.P Although the sparse index provides the greatest coverage, the dense index provides more deduplication advice. For most workloads, given the same amount of memory, the difference in deduplication rates between dense and sparse indexes is negligible. - +.P A dense index with 1 GiB of RAM maintains a 1 TiB deduplication window, while a sparse index with 1 GiB of RAM maintains a 10 TiB deduplication window. In general, 1 GiB is sufficient for 4 TiB of physical space with a dense index and 40 TiB with a sparse index. -.SS 7. Storage space requirements +. +.SS \n+[step]. Storage space requirements +. You can configure a VDOPoolLV to use up to 256 TiB of physical storage. Only a certain part of the physical storage is usable to store data. This section provides the calculations to determine the usable size of a VDO-managed volume. - +.P The VDO target requires storage for two types of VDO metadata and for the UDS index: -.TP -\(bu +.IP \(bu 2 The first type of VDO metadata uses approximately 1 MiB for each 4 GiB of physical storage plus an additional 1 MiB per slab. -.TP -\(bu +.IP \(bu The second type of VDO metadata consumes approximately 1.25 MiB for each 1 GiB of logical storage, rounded up to the nearest slab. -.TP -\(bu +.IP \(bu The amount of storage required for the UDS index depends on the type of index and the amount of RAM allocated to the index. For each 1 GiB of RAM, a dense UDS index uses 17 GiB of storage and a sparse UDS index will use 170 GiB of storage. - +. .SH SEE ALSO +. +.nh +.ad l .BR lvm (8), .BR lvm.conf (5), .BR lvmconfig (8), @@ -355,7 +393,9 @@ a dense UDS index uses 17 GiB of storage and a sparse UDS index will use .BR lvresize (8), .BR lvremove (8), .BR lvs (8), +.P .BR vdo (8), .BR vdoformat (8), .BR vdostats (8), +.P .BR mkfs (8) |