mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-22 17:35:59 +03:00
3bb9eda97c
Better formatting. More consistent naming. Better clarity.
630 lines
24 KiB
Groff
630 lines
24 KiB
Groff
.TH LVM 8 "LVM TOOLS #VERSION#" "Sistina Software UK" \" -*- nroff -*-
|
|
.SH NAME
|
|
lvm \- LVM2 tools
|
|
.SH SYNOPSIS
|
|
.B lvm
|
|
[command | file]
|
|
.SH DESCRIPTION
|
|
lvm provides the command-line tools for LVM2. A separate
|
|
manual page describes each command in detail.
|
|
.LP
|
|
If \fBlvm\fP is invoked with no arguments it presents a readline prompt
|
|
(assuming it was compiled with readline support).
|
|
LVM commands may be entered interactively at this prompt with
|
|
readline facilities including history and command name and option
|
|
completion. Refer to \fBreadline\fP(3) for details.
|
|
.LP
|
|
If \fBlvm\fP is invoked with argv[0] set to the name of a specific
|
|
LVM command (for example by using a hard or soft link) it acts as
|
|
that command.
|
|
.LP
|
|
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.
|
|
.LP
|
|
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
|
|
as "vg0/lvol0". Where a list of VGs is required but is left empty,
|
|
a list of all VGs will be substituted. Where a list of LVs is required
|
|
but a VG is given, a list of all the LVs in that VG will be substituted.
|
|
So \fBlvdisplay vg0\fP will display all the LVs in "vg0".
|
|
Tags can also be used - see \fB\-\-addtag\fP below.
|
|
.LP
|
|
One advantage of using the built-in shell is that configuration
|
|
information gets cached internally between commands.
|
|
.LP
|
|
A file containing a simple script with one command per line
|
|
can also be given on the command line. The script can also be
|
|
executed directly if the first line is #! followed by the absolute
|
|
path of \fBlvm\fP.
|
|
.SH BUILT-IN COMMANDS
|
|
The following commands are built into lvm without links normally
|
|
being created in the filesystem for them.
|
|
.TP
|
|
\fBdumpconfig\fP \(em Display the configuration information after
|
|
loading \fBlvm.conf\fP(5) and any other configuration files.
|
|
.TP
|
|
\fBdevtypes\fP \(em Display the recognised built-in block device types.
|
|
.TP
|
|
\fBformats\fP \(em Display recognised metadata formats.
|
|
.TP
|
|
\fBhelp\fP \(em Display the help text.
|
|
.TP
|
|
\fBpvdata\fP \(em Not implemented in LVM2.
|
|
.TP
|
|
\fBsegtypes\fP \(em Display recognised Logical Volume segment types.
|
|
.TP
|
|
\fBtags\fP \(em Display any tags defined on this host.
|
|
.TP
|
|
\fBversion\fP \(em Display version information.
|
|
.LP
|
|
.SH COMMANDS
|
|
The following commands implement the core LVM functionality.
|
|
.TP
|
|
\fBpvchange\fP \(em Change attributes of a Physical Volume.
|
|
.TP
|
|
\fBpvck\fP \(em Check Physical Volume metadata.
|
|
.TP
|
|
\fBpvcreate\fP \(em Initialize a disk or partition for use by LVM.
|
|
.TP
|
|
\fBpvdisplay\fP \(em Display attributes of a Physical Volume.
|
|
.TP
|
|
\fBpvmove\fP \(em Move Physical Extents.
|
|
.TP
|
|
\fBpvremove\fP \(em Remove a Physical Volume.
|
|
.TP
|
|
\fBpvresize\fP \(em Resize a disk or partition in use by LVM2.
|
|
.TP
|
|
\fBpvs\fP \(em Report information about Physical Volumes.
|
|
.TP
|
|
\fBpvscan\fP \(em Scan all disks for Physical Volumes.
|
|
.TP
|
|
\fBvgcfgbackup\fP \(em Backup Volume Group descriptor area.
|
|
.TP
|
|
\fBvgcfgrestore\fP \(em Restore Volume Group descriptor area.
|
|
.TP
|
|
\fBvgchange\fP \(em Change attributes of a Volume Group.
|
|
.TP
|
|
\fBvgck\fP \(em Check Volume Group metadata.
|
|
.TP
|
|
\fBvgconvert\fP \(em Convert Volume Group metadata format.
|
|
.TP
|
|
\fBvgcreate\fP \(em Create a Volume Group.
|
|
.TP
|
|
\fBvgdisplay\fP \(em Display attributes of Volume Groups.
|
|
.TP
|
|
\fBvgexport\fP \(em Make volume Groups unknown to the system.
|
|
.TP
|
|
\fBvgextend\fP \(em Add Physical Volumes to a Volume Group.
|
|
.TP
|
|
\fBvgimport\fP \(em Make exported Volume Groups known to the system.
|
|
.TP
|
|
\fBvgimportclone\fP \(em Import and rename duplicated Volume Group (e.g. a hardware snapshot).
|
|
.TP
|
|
\fBvgmerge\fP \(em Merge two Volume Groups.
|
|
.TP
|
|
\fBvgmknodes\fP \(em Recreate Volume Group directory and Logical Volume special files
|
|
.TP
|
|
\fBvgreduce\fP \(em Reduce a Volume Group by removing one or more
|
|
Physical Volumes.
|
|
.TP
|
|
\fBvgremove\fP \(em Remove a Volume Group.
|
|
.TP
|
|
\fBvgrename\fP \(em Rename a Volume Group.
|
|
.TP
|
|
\fBvgs\fP \(em Report information about Volume Groups.
|
|
.TP
|
|
\fBvgscan\fP \(em Scan all disks for Volume Groups and rebuild caches.
|
|
.TP
|
|
\fBvgsplit\fP \(em Split a Volume Group into two, moving any logical
|
|
volumes from one Volume Group to another by moving entire Physical
|
|
Volumes.
|
|
.TP
|
|
\fBlvchange\fP \(em Change attributes of a Logical Volume.
|
|
.TP
|
|
\fBlvconvert\fP \(em Convert a Logical Volume from linear to mirror or snapshot.
|
|
.TP
|
|
\fBlvcreate\fP \(em Create a Logical Volume in an existing Volume Group.
|
|
.TP
|
|
\fBlvdisplay\fP \(em Display attributes of a Logical Volume.
|
|
.TP
|
|
\fBlvextend\fP \(em Extend the size of a Logical Volume.
|
|
.TP
|
|
\fBlvmchange\fP \(em Change attributes of the Logical Volume Manager.
|
|
.TP
|
|
\fBlvmdiskscan\fP \(em Scan for all devices visible to LVM2.
|
|
.TP
|
|
\fBlvmdump\fP \(em Create lvm2 information dumps for diagnostic purposes.
|
|
.TP
|
|
\fBlvreduce\fP \(em Reduce the size of a Logical Volume.
|
|
.TP
|
|
\fBlvremove\fP \(em Remove a Logical Volume.
|
|
.TP
|
|
\fBlvrename\fP \(em Rename a Logical Volume.
|
|
.TP
|
|
\fBlvresize\fP \(em Resize a Logical Volume.
|
|
.TP
|
|
\fBlvs\fP \(em Report information about Logical Volumes.
|
|
.TP
|
|
\fBlvscan\fP \(em Scan (all disks) for Logical Volumes.
|
|
.TP
|
|
The following commands are not implemented in LVM2 but might be in the future: lvmsadc, lvmsar, pvdata.
|
|
.SH OPTIONS
|
|
The following options are available for many of the commands.
|
|
They are implemented generically and documented here rather
|
|
than repeated on individual manual pages.
|
|
.TP
|
|
.BR \-h ", " \-? ", " \-\-help
|
|
Display the help text.
|
|
.TP
|
|
.B \-\-version
|
|
Display version information.
|
|
.TP
|
|
.BR \-v ", " \-\-verbose
|
|
Set verbose level. Repeat from 1 to 3 times to increase the detail
|
|
of messages sent to stdout and stderr. Overrides config file setting.
|
|
.TP
|
|
.BR \-d ", " \-\-debug
|
|
Set debug level. Repeat from 1 to 6 times to increase the detail of
|
|
messages sent to the log file and/or syslog (if configured).
|
|
Overrides config file setting.
|
|
.TP
|
|
.BR \-q ", " \-\-quiet
|
|
Suppress output and log messages.
|
|
Overrides \fB\-d\fP and \fB\-v\fP.
|
|
.TP
|
|
.BR \-\-yes
|
|
Don't prompt for confirmation interactively but instead always assume the
|
|
answer is 'yes'. Take great care if you use this!
|
|
.TP
|
|
.BR \-t ", " \-\-test
|
|
Run in test mode. Commands will not update metadata.
|
|
This is implemented by disabling all metadata writing but nevertheless
|
|
returning success to the calling function. This may lead to unusual
|
|
error messages in multi-stage operations if a tool relies on reading
|
|
back metadata it believes has changed but hasn't.
|
|
.TP
|
|
.BR \-\-driverloaded " {" \fIy | \fIn }
|
|
Whether or not the device-mapper kernel driver is loaded.
|
|
If you set this to \fIn\fP, no attempt will be made to contact the driver.
|
|
.TP
|
|
.BR \-A ", " \-\-autobackup " {" \fIy | \fIn }
|
|
Whether or not to metadata should be backed up automatically after a change.
|
|
You are strongly advised not to disable this!
|
|
See \fBvgcfgbackup\fP(8).
|
|
.TP
|
|
.BR \-P ", " \-\-partial
|
|
When set, the tools will do their best to provide access to Volume Groups
|
|
that are only partially available (one or more Physical Volumes belonging
|
|
to the Volume Group are missing from the system). Where part of a logical
|
|
volume is missing, \fB/dev/ioerror\fP will be substituted, and you could use
|
|
\fBdmsetup\fP(8) to set this up to return I/O errors when accessed,
|
|
or create it as a large block device of nulls. Metadata may not be
|
|
changed with this option. To insert a replacement Physical Volume
|
|
of the same or large size use \fBpvcreate \-u\fP to set the uuid to
|
|
match the original followed by \fBvgcfgrestore\fP(8).
|
|
.TP
|
|
.BR \-M ", " \-\-metadatatype " " \fIType
|
|
Specifies which type of on-disk metadata to use, such as \fIlvm1\fP
|
|
or \fIlvm2\fP, which can be abbreviated to \fI1\fP or \fI2\fP respectively.
|
|
The default (\fIlvm2\fP) can be changed by setting \fBformat\fP
|
|
in the \fBglobal\fP section of the config file.
|
|
.TP
|
|
.B \-\-ignorelockingfailure
|
|
This lets you proceed with read-only metadata operations such as
|
|
\fBlvchange \-ay\fP and \fBvgchange \-ay\fP even if the locking module fails.
|
|
One use for this is in a system init script if the lock directory
|
|
is mounted read-only when the script runs.
|
|
.TP
|
|
.B \-\-ignoreskippedcluster
|
|
Use to avoid exiting with an non-zero status code if the command is run
|
|
without clustered locking and some clustered Volume Groups have to be
|
|
skipped over.
|
|
.TP
|
|
.B \-\-addtag \fITag
|
|
Add the tag \fITag\fP to a PV, VG or LV.
|
|
Supply this argument multiple times to add more than one tag at once.
|
|
A tag is a word that can be used to group LVM2 objects of the same type
|
|
together.
|
|
Tags can be given on the command line in place of PV, VG or LV
|
|
arguments. Tags should be prefixed with @ to avoid ambiguity.
|
|
Each tag is expanded by replacing it with all objects possessing
|
|
that tag which are of the type expected by its position on the command line.
|
|
PVs can only possess tags while they are part of a Volume Group:
|
|
PV tags are discarded if the PV is removed from the VG.
|
|
As an example, you could tag some LVs as \fBdatabase\fP and others
|
|
as \fBuserdata\fP and then activate the database ones
|
|
with \fBlvchange \-ay @database\fP.
|
|
Objects can possess multiple tags simultaneously.
|
|
Only the new LVM2 metadata format supports tagging: objects using the
|
|
LVM1 metadata format cannot be tagged because the on-disk format does not
|
|
support it.
|
|
Characters allowed in tags are:
|
|
.B A-Z a-z 0-9 _ + . -
|
|
and as of version 2.02.78 the following characters are also accepted:
|
|
.B / = ! : # &
|
|
.TP
|
|
.B \-\-deltag \fITag
|
|
Delete the tag \fITag\fP from a PV, VG or LV, if it's present.
|
|
Supply this argument multiple times to remove more than one tag at once.
|
|
.TP
|
|
.IR \fB\-\-alloc \ { anywhere | contiguous | cling | inherit | normal }
|
|
Selects the allocation policy when a command needs to allocate
|
|
Physical Extents from the Volume Group.
|
|
Each Volume Group and Logical Volume has an allocation policy defined.
|
|
The default for a Volume Group is \fInormal\fP which applies
|
|
common-sense rules such as not placing parallel stripes on the same
|
|
Physical Volume. The default for a Logical Volume is \fIinherit\fP
|
|
which applies the same policy as for the Volume Group. These policies can
|
|
be changed using \fBlvchange\fP(8) and \fBvgchange\fP(8) or overridden
|
|
on the command line of any command that performs allocation.
|
|
The \fIcontiguous\fP policy requires that new Physical Extents be placed adjacent
|
|
to existing Physical Extents.
|
|
The \fIcling\fP policy places new Physical Extents on the same Physical
|
|
Volume as existing Physical Extents in the same stripe of the Logical Volume.
|
|
If there are sufficient free Physical Extents to satisfy
|
|
an allocation request but \fInormal\fP doesn't use them,
|
|
\fIanywhere\fP will - even if that reduces performance by
|
|
placing two stripes on the same Physical Volume.
|
|
.TP
|
|
.IR \fB\-\-profile \ ProfileName
|
|
Selects the configuration profile to use when processing an LVM command.
|
|
In addition to that, when creating a Volume Group or a Logical Volume,
|
|
it causes the ProfileName to be stored in metadata for each Volume Group
|
|
or Logical Volume. If the profile is stored in metadata, it is automatically
|
|
applied next time the Volume Group or the Logical Volume is processed and the
|
|
use of --profile is not necessary when running LVM commands further. See also
|
|
\fBlvm.conf\fP(5) for more information about \fBprofile config\fP and the
|
|
way it fits with other LVM configuration methods.
|
|
.TP
|
|
.IR \fB\-\-config \ ConfigurationString
|
|
Uses 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. See \fBlvm.conf\fP(5)
|
|
for more information about \fBdirect config override on command line\fP and the
|
|
way it fits with other LVM configuration methods.
|
|
.SH ENVIRONMENT VARIABLES
|
|
.TP
|
|
.B HOME
|
|
Directory containing \fI.lvm_history\fP if the internal readline
|
|
shell is invoked.
|
|
.TP
|
|
.B LVM_SYSTEM_DIR
|
|
Directory containing \fBlvm.conf\fP(5) and other LVM system files.
|
|
Defaults to "#DEFAULT_SYS_DIR#".
|
|
.TP
|
|
.B LVM_SUPPRESS_FD_WARNINGS
|
|
Suppress warnings about openned file descriptors, when lvm command
|
|
is executed.
|
|
.TP
|
|
.B LVM_VG_NAME
|
|
The Volume Group name that is assumed for
|
|
any reference to a Logical Volume that doesn't specify a path.
|
|
Not set by default.
|
|
.TP
|
|
.B LVM_LVMETAD_PIDFILE
|
|
Path for the lvmetad pid file.
|
|
.TP
|
|
.B LVM_LVMETAD_SOCKET
|
|
Path for the lvmetad socket file.
|
|
.SH VALID NAMES
|
|
The following characters are valid for VG and LV names:
|
|
.B a-z A-Z 0-9 + _ . -
|
|
.LP
|
|
VG and LV names cannot begin with a hyphen.
|
|
There are also various reserved names that are used internally by lvm that can not be used as LV or VG names.
|
|
A VG cannot be called anything that exists in /dev/ at the time of creation, nor can it be called '.' or '..'.
|
|
A LV cannot be called '.' '..' 'snapshot' or 'pvmove'. The LV name may also not contain
|
|
the strings '_mlog', '_mimage', '_rimage', '_tdata', '_tmeta'.
|
|
.SH ALLOCATION
|
|
When an operation needs to allocate Physical Extents for one or more
|
|
Logical Volumes, the tools proceed as follows:
|
|
|
|
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.
|
|
|
|
Then they try each allocation policy in turn, starting with the strictest
|
|
policy (\fIcontiguous\fP) and ending with the allocation policy specified
|
|
using \fB\-\-alloc\fP or set as the default for the particular Logical
|
|
Volume or Volume Group concerned. For each policy, working from the
|
|
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.
|
|
|
|
The restrictions are as follows:
|
|
|
|
\fIContiguous\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.
|
|
|
|
\fICling\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
|
|
configuration parameter allocation/cling_tag_list is defined, then two
|
|
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.
|
|
|
|
When a Logical Volume is striped or mirrored, the above restrictions are
|
|
applied independently to each stripe or mirror image (leg) that needs
|
|
space.
|
|
|
|
\fINormal\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.
|
|
|
|
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
|
|
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.
|
|
|
|
When allocating thin pool metadata, similar considerations to those of a
|
|
mirror log in the last paragraph apply based on the value of the
|
|
allocation/thin_pool_metadata_require_separate_pvs configuration
|
|
parameter.
|
|
|
|
If you rely upon any layout behaviour beyond that documented here, be
|
|
aware that it might change in future versions of the code.
|
|
|
|
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
|
|
they are listed, but there is no guarantee that future releases will
|
|
maintain that property. If it is important to obtain a specific layout
|
|
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.
|
|
|
|
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.
|
|
|
|
.SH LOGICAL VOLUME TYPES
|
|
Some logical volume types are simple to create and can be done with a
|
|
single \fBlvcreate\fP(8) command. The linear and striped logical
|
|
volume types are an example of this. Other logical volume types may
|
|
require more than one command to create. The cache and thin provisioning
|
|
types are examples of this.
|
|
|
|
.br
|
|
.SS Cache
|
|
The \fIcache\fP logical volume type uses a small and fast LV to improve
|
|
the performance of a large and slow LV. It does this by storing the
|
|
frequently used blocks on the faster LV.
|
|
LVM refers to the small fast LV as a \fBcache pool LV\fP. The large
|
|
slow LV is called the \fBorigin LV\fP. Due to requirements from dm-cache
|
|
(the kernel driver), LVM further splits the cache pool LV into two
|
|
devices - the \fBcache data LV\fP and \fBcache metadata LV\fP. The cache
|
|
data LV is where copies of data blocks are kept from the
|
|
origin LV to increase speed. The cache metadata LV holds the
|
|
accounting information that specifies where data blocks are stored (e.g.
|
|
on the origin LV or on the cache data LV). Users should be familiar with
|
|
these LVs if they wish to create the best and most robust cached
|
|
logical volumes.
|
|
|
|
.SS Cache Terms
|
|
.nf
|
|
origin LV OriginLV large slow LV
|
|
cache data LV CacheDataLV small fast LV for cache pool data
|
|
cache metadata LV CacheMetaLV small fast LV for cache pool metadata
|
|
cache pool LV CachePoolLV CacheDataLV + CacheMetaLV
|
|
cache LV CacheLV OriginLV + CachePoolLV
|
|
.fi
|
|
|
|
.SS Cache Steps
|
|
The steps to create a logical volume of \fIcache\fP type are as follows:
|
|
.TP
|
|
0.
|
|
Create an LV or identify an existing LV to be the origin LV.
|
|
.TP
|
|
1.
|
|
Create the cache data LV. The size of this LV is the size of the cache
|
|
and will be reported as the size of the cache pool LV.
|
|
.TP
|
|
2.
|
|
Create the cache metadata LV.
|
|
The size of this LV should be 1000 times smaller than the cache data LV
|
|
with a minimum size of 8MiB.
|
|
.TP
|
|
3.
|
|
Create the cache pool LV by combining the cache data LV (from step 1)
|
|
and cache metadata LV (from step 2). When performing this step,
|
|
behavioral characteristics of the cache pool LV can be set.
|
|
The name of the cache pool LV takes the name of the cache data LV and
|
|
the cache data LV and cache metadata LV are renamed
|
|
to CachePoolLV_cdata and CachePoolLV_cmeta.
|
|
.TP
|
|
4.
|
|
Create a cache LV by linking the cache pool LV to the origin LV.
|
|
The user accessible cache LV takes the name of the origin LV,
|
|
while the origin LV becomes a hidden LV with the name
|
|
OriginLV_corig. Users can perform this step while the origin LV
|
|
is in use.
|
|
|
|
.P
|
|
The steps above represent the best way to create a cache LV.
|
|
They provide the most options and have the ability to create the
|
|
most robust logical volumes. The examples below illustrate how these
|
|
steps might be used in practice.
|
|
|
|
.SS Cache Commands
|
|
.nf
|
|
0. create OriginLV
|
|
lvcreate -L LargeSize -n OriginLV VG SlowPVs
|
|
|
|
1. create CacheDataLV
|
|
lvcreate -L CacheSize -n CacheDataLV VG FastPVs
|
|
|
|
2. create CacheMetaLV
|
|
lvcreate -L MetaSize -n CacheMetaLV VG FastPVs
|
|
|
|
3. create CachePoolLV
|
|
lvconvert --type cache-pool --poolmetadata VG/CacheMetaLV VG/CacheDataLV
|
|
CachePoolLV takes the name of CacheDataLV.
|
|
CacheDataLV is renamed CachePoolLV_cdata and becomes hidden.
|
|
CacheMetaLV is renamed CachePoolLV_cmeta and becomes hidden.
|
|
|
|
4. create CacheLV
|
|
lvconvert --type cache --cachepool VG/CachePoolLV VG/OriginLV
|
|
CacheLV takes the name of OriginLV.
|
|
OriginLV is renamed OriginLV_corig and becomes hidden.
|
|
.fi
|
|
|
|
.SS Cache Examples
|
|
|
|
.B Example 1:
|
|
Creating a simple cache LV.
|
|
.br
|
|
|
|
.nf
|
|
0. Create the origin LV
|
|
# lvcreate -L 10G -n lvx vg /dev/slow_dev
|
|
|
|
1. Create a cache data LV
|
|
# lvcreate -L 1G -n lvx_cache vg /dev/fast_dev
|
|
|
|
2. Create a cache metadata LV (~1/1000th size of CacheDataLV or 8MiB)
|
|
# lvcreate -L 8M -n lvx_cache_meta vg /dev/fast_dev
|
|
|
|
3. Create a cache pool LV, combining cache data LV and cache metadata LV
|
|
# lvconvert --type cache-pool --poolmetadata vg/lvx_cache_meta \\
|
|
vg/lvx_cache
|
|
|
|
4. Create a cached LV by combining the cache pool LV and origin LV
|
|
# lvconvert --type cache --cachepool vg/lvx_cache vg/lvx
|
|
.fi
|
|
|
|
.B Example 2:
|
|
Creating a cache LV with a fault tolerant cache pool LV.
|
|
|
|
Users who are concerned about the possibility of failures in their fast devices
|
|
that could lead to data loss might consider making their cache pool sub-LVs
|
|
redundant. Example 2 illustrates how to do that. Note that only steps
|
|
1 & 2 change.
|
|
|
|
.nf
|
|
0. Create an origin LV we wish to cache
|
|
# lvcreate -L 10G -n lvx vg /dev/slow_devs
|
|
|
|
1. Create a 2-way RAID1 cache data LV
|
|
# lvcreate --type raid1 -m 1 -L 1G -n lvx_cache vg \\
|
|
/dev/fast1 /dev/fast2
|
|
|
|
2. Create a 2-way RAID1 cache metadata LV
|
|
# lvcreate --type raid1 -m 1 -L 8M -n lvx_cache_meta vg \\
|
|
/dev/fast1 /dev/fast2
|
|
|
|
3. Create a cache pool LV combining cache data LV and cache metadata LV
|
|
# lvconvert --type cache-pool --poolmetadata vg/lvx_cache_meta \\
|
|
vg/lvx_cache
|
|
|
|
4. Create a cached LV by combining the cache pool LV and origin LV
|
|
# lvconvert --type cache --cachepool vg/lvx_cache vg/lvx
|
|
.fi
|
|
|
|
.B Example 3:
|
|
Creating a simple cache LV with \fIwritethough\fP caching.
|
|
|
|
Some users wish to ensure that any data written will be stored both in the
|
|
cache pool LV and on the origin LV. The loss of a device associated with
|
|
the cache pool LV in this case would not mean the loss of any data. When
|
|
combining the cache data LV and the cache metadata LV to form the cache pool
|
|
LV, properties of the cache can be specified - in this case,
|
|
\fIwritethrough\fP vs. \fIwriteback\fP. Note that only step 3 is affected
|
|
in this case.
|
|
|
|
.nf
|
|
0. Create an origin LV we wish to cache (yours may already exist)
|
|
# lvcreate -L 10G -n lvx vg /dev/slow
|
|
|
|
1. Create a cache data LV
|
|
# lvcreate -L 1G -n lvx_cache vg /dev/fast
|
|
|
|
2. Create a cache metadata LV
|
|
# lvcreate -L 8M -n lvx_cache_meta vg /dev/fast
|
|
|
|
3. Create a cache pool LV specifying cache mode "writethrough"
|
|
# lvconvert --type cache-pool --poolmetadata vg/lvx_cache_meta \\
|
|
--cachemode writethrough vg/lvx_cache
|
|
|
|
4. Create a cache LV by combining the cache pool LV and origin LV
|
|
# lvconvert --type cache --cachepool vg/lvx_cache vg/lvx
|
|
.fi
|
|
|
|
.SS Removing Cache Logical Volumes
|
|
If you wish to remove all logical volumes associated with a cache
|
|
LV, you must remove both top-level, user-visible devices.
|
|
The cache metadata LV and cache data LV cannot be removed
|
|
directly. If only the cache pool LV is specfied for removal, any cached
|
|
blocks not yet on the origin LV will be flush, the cache pool LV will be
|
|
removed, and the now un-cached origin LV will remain. If the user
|
|
specifies a cache LV for removal, then the origin LV is
|
|
removed and only the cache pool LV will remain. The cache pool LV can then
|
|
be used to create another cache LV with a different origin LV if desired.
|
|
|
|
When users intend to remove all logical volumes associated with a
|
|
cache LV, it is generally better to start with the origin LV and then
|
|
remove the cache pool LV. If the operations are performed in the
|
|
reverse order, the user will have to wait for the contents of the
|
|
cache pool LV to be flushed before the origin LV is removed. This
|
|
could take some time.
|
|
|
|
.SH DIAGNOSTICS
|
|
All tools return a status code of zero on success or non-zero on failure.
|
|
.SH FILES
|
|
.I #DEFAULT_SYS_DIR#/lvm.conf
|
|
.br
|
|
.I $HOME/.lvm_history
|
|
.SH SEE ALSO
|
|
.BR lvm.conf (5),
|
|
.BR clvmd (8),
|
|
.BR lvchange (8),
|
|
.BR lvcreate (8),
|
|
.BR lvdisplay (8),
|
|
.BR lvextend (8),
|
|
.BR lvmchange (8),
|
|
.BR lvmdiskscan (8),
|
|
.BR lvreduce (8),
|
|
.BR lvremove (8),
|
|
.BR lvrename (8),
|
|
.BR lvresize (8),
|
|
.BR lvs (8),
|
|
.BR lvscan (8),
|
|
.BR pvchange (8),
|
|
.BR pvck (8),
|
|
.BR pvcreate (8),
|
|
.BR pvdisplay (8),
|
|
.BR pvmove (8),
|
|
.BR pvremove (8),
|
|
.BR pvs (8),
|
|
.BR pvscan (8),
|
|
.BR vgcfgbackup (8),
|
|
.BR vgchange (8),
|
|
.BR vgck (8),
|
|
.BR vgconvert (8),
|
|
.BR vgcreate (8),
|
|
.BR vgdisplay (8),
|
|
.BR vgextend (8),
|
|
.BR vgimport (8),
|
|
.BR vgimportclone (8),
|
|
.BR vgmerge (8),
|
|
.BR vgmknodes (8),
|
|
.BR vgreduce (8),
|
|
.BR vgremove (8),
|
|
.BR vgrename (8),
|
|
.BR vgs (8),
|
|
.BR vgscan (8),
|
|
.BR vgsplit (8),
|
|
.BR readline (3)
|