mirror of
git://sourceware.org/git/lvm2.git
synced 2025-01-04 09:18:36 +03:00
00ce01e52d
Thin pools use "thin-pool" for the segment type name. To be consistent, we use "cache-pool" instead of "cache_pool".
592 lines
24 KiB
Groff
592 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 ADVANCED 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 thinly provisioned
|
|
types are examples of this. This section is devoted to explaining the
|
|
creation and monitoring of the more advanced types of logical volumes in
|
|
LVM. While the specifics of each command can be found in their respective
|
|
man page, here you will find examples and best practices that may invoke
|
|
multiple commands.
|
|
.br
|
|
.SS Cache Logical Volumes
|
|
A cache logical volume is one that allows a small and fast block device to
|
|
be used to improve the performance of larger and slower block devices. It
|
|
does this by storing the more frequently used blocks on the faster device.
|
|
LVM refers to the small fast device as a "cache pool". The large slow device
|
|
is called the "origin". Due to requirements from dm-cache (the kernel
|
|
driver), LVM further splits the "cache pool" into two devices - the "cache pool
|
|
metadata" and "cache pool data" devices. The "cache pool data" device is where
|
|
copies of data blocks are kept from the origin to increase speed. The "cache
|
|
pool metadata" device holds the accounting information that specifies where
|
|
data blocks are stored (e.g. on the "origin" or in the "cache pool data" device).
|
|
Users should be familiar with these three devices should they wish to create
|
|
the best and most robust cached logical volumes.
|
|
|
|
.SS Creating Cache Logical Volumes
|
|
The steps to create a logical volume of cache type are as follows:
|
|
.TP
|
|
1)
|
|
Create the cache pool's data device. The size of this device directly
|
|
correlates to the size of the cache and will ultimately be reported as
|
|
the size of the cache pool.
|
|
.TP
|
|
2)
|
|
Create the cache pool's metadata device. The size of this device is
|
|
loosely related to the size of the data device. Generally, a user can
|
|
size this 1000 times smaller than the cache pool data device with a
|
|
minimum size of 8MiB.
|
|
.TP
|
|
3)
|
|
Create the cache pool by combining the cache pool data and metadata
|
|
logical volumes created in steps 1 & 2. When performing this step,
|
|
the user can specify behavioral characteristics of the cache pool if
|
|
they wish. If no new name is specified when combining, the name of the
|
|
cache pool data device will become the name of the cachepool. The sub-LVs
|
|
are then renamed to <name>_cdata and <name>_cmeta.
|
|
.TP
|
|
4)
|
|
Create a cached logical volume by linking the cache pool to an existing
|
|
logical volume. The user accessible cached LV keeps the name of the origin,
|
|
while the actual origin device becomes a hidden LV with the name
|
|
<origial name>_corig. Users can perform this step while the device which
|
|
is to be cached is in use.
|
|
|
|
.P
|
|
The above steps represent the best way to create a cached logical volume.
|
|
They provide access to the most options and have the ability to create the
|
|
most robust logical volumes. The examples below will illustrate how these
|
|
steps might be used in practice.
|
|
|
|
.B Example 1:
|
|
Creating a simple cache device named, "my_lv".
|
|
.br
|
|
|
|
.nf
|
|
# Create a device we wish to cache (yours may already exist)
|
|
Step-0> lvcreate -L 10G -n my_lv my_vg /dev/slow_dev
|
|
|
|
# Create a cache pool data LV
|
|
Step-1> lvcreate -L 1G -n cachepool my_vg /dev/fast_dev
|
|
|
|
# Create a cache pool metadata LV (~1/1000th size of pool data)
|
|
Step-2> lvcreate -L 8M -n meta my_vg /dev/fast_dev
|
|
|
|
# Combine cache pool sub-LVs into a cache pool.
|
|
Step-3> lvconvert --type cache-pool vg/cachepool --poolmetadata vg/meta
|
|
|
|
# Combine the cache pool and origin to create a cached LV
|
|
Step-4> lvconvert --type cache my_vg/my_lv --cachepool vg/cachepool
|
|
.fi
|
|
|
|
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 just that. Note that only steps
|
|
1 & 2 change slightly.
|
|
|
|
.B Example 2:
|
|
Creating a cache LV with a fault tolerant cache pool.
|
|
|
|
.nf
|
|
# Create a device we wish to cache (yours may already exist)
|
|
Step-0> lvcreate -L 10G -n my_lv my_vg /dev/slow_dev
|
|
|
|
# Create a 2-way RAID1 cache pool data LV
|
|
Step-01> lvcreate --type raid1 -L 1G -n cachepool my_vg /dev/fast[12]
|
|
|
|
# Create a 2-way RAID1 cache pool metadata LV
|
|
Step-2> lvcreate --type raid1 -L 8M -n meta my_vg /dev/fast1 /dev/fast2
|
|
|
|
# Combine cache pool sub-LVs into a cache pool.
|
|
Step-3> lvconvert --type cache-pool vg/cachepool --poolmetadata vg/meta
|
|
|
|
# Combine the cache pool and origin to create a cached LV
|
|
Step-4> lvconvert --type cache my_vg/my_lv --cachepool vg/cachepool
|
|
.fi
|
|
|
|
Some users wish to ensure that any data written will be stored both in the
|
|
cache pool and on the origin. The loss of the cache device in this case
|
|
would not mean the loss of any data. When combining the cache pool's sub-LVs
|
|
to form the cachepool, behavioral characteristics of the cache can be
|
|
specified - in this case, writethrough vs. writeback. Note that only step
|
|
3 is affected in this case.
|
|
|
|
.B Example 3:
|
|
Creating a simple cache device with "writethough" caching.
|
|
|
|
.nf
|
|
# Create a device we wish to cache (yours may already exist)
|
|
Step-0> lvcreate -L 10G -n my_lv my_vg /dev/slow_dev
|
|
|
|
# Create a cache pool data LV
|
|
Step-1> lvcreate -L 1G -n cachepool my_vg /dev/fast_dev
|
|
|
|
# Create a cache pool metadata LV
|
|
Step-2> lvcreate -L 8M -n meta my_vg /dev/fast_dev
|
|
|
|
# Combine cache pool sub-LVs into a cache pool and specify "writethough".
|
|
Step-3> lvconvert --type cache-pool vg/cachepool \\
|
|
--poolmetadata vg/meta --cachemode writethrough -n cachepool
|
|
|
|
# Combine the cache pool and origin to create a cached LV
|
|
Step-4> lvconvert --type cache my_vg/my_lv --cachepool vg/cachepool
|
|
.fi
|
|
|
|
.SS Removing Cache Logical Volumes
|
|
If users wish to remove all logical volumes associated with a cached
|
|
logical volume, they must remove both top-level, user visible devices.
|
|
The cache pool metadata and data logical volumes cannot be removed
|
|
directly. If only the cache pool is specfied for removal, any cached
|
|
blocks not yet on the origin will be flush, the cache pool will be
|
|
removed, and the now un-cached origin will remain. If the user
|
|
specifies a cached LV for removal, then the origin device is
|
|
removed and only the cache pool will remain. The cache pool can then be
|
|
used to create another cache LV with a different origin if desired.
|
|
|
|
When users intend to remove all logical volumes associated with a
|
|
cached LV, it is generally better to start with the origin and then
|
|
remove the cache pool. If the operations are performed in the
|
|
reverse order, the user will have to wait for the contents of the
|
|
cache pool to be flushed before they remove the origin. 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)
|