Document OALWP03950320
Document Id: OALWP03950320
Date Loaded: 03-21-95
Description: HP-UX 10.0 Logical Volume Manager White Paper
HP-UX 10.0 Logical Volume Manager White Paper
HP 9000 Series 700/800 Computers
March 1995, First Edition
LEGAL NOTICES
The information in this document is subject to change without notice.
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose.
Hewlett-Packard shall not be held liable for errors contained herein
or direct, indirect, special, incidental or consequential damages in
connection with the furnishing, performance, or use of this material.
Warranty. A copy of the specific warranty terms applicable to
your Hewlett-Packard product and replacement parts can be obtained
from your local Sales and Service Office.
Restricted Rights Legend. Use, duplication, or disclosure by
the U.S. Government Department is subject to restrictions as set
forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and
Computer Software clause at DFARS 252.227-7013 for DOD agencies, and
subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software
Restricted Rights clause at FAR 52.227-19 for other agencies.
HEWLETT-PACKARD COMPANY
3000 Hanover Street
Palo Alto, California 94304 U.S.A.
Use of this manual and flexible disk(s) or tape cartridge(s) supplied
for this pack is restricted to this product only. Additional copies
of the programs may be made for security and back-up purposes only.
Resale of the programs in their present form or with alterations, is
expressly prohibited.
Copyright Notices. (C)copyright 1983-95 Hewlett-Packard Company,
all rights reserved.
Reproduction, adaptation, or translation of this document without prior
written permission is prohibited, except as allowed under the copyright laws.
(C)copyright 1979, 1980, 1983, 1985-93 Regents of the University
of California
This software is based in part on the Fourth Berkeley Software
Distribution under license from the Regents of the University of
California.
(C)copyright 1980, 1984, 1986 Novell, Inc.
(C)copyright 1986-1992 Sun Microsystems, Inc.
(C)copyright 1985-86, 1988 Massachusetts Institute of Technology.
(C)copyright 1989-93 The Open Software Foundation, Inc.
(C)copyright 1986 Digital Equipment Corporation.
(C)copyright 1990 Motorola, Inc.
(C)copyright 1990, 1991, 1992 Cornell University
(C)copyright 1989-1991 The University of Maryland.
(C)copyright 1988 Carnegie Mellon University.
Trademark Notices. UNIX is a registered trademark in the United States and
other countries, licensed exclusively through X/Open Company Limited.
X Window System is a trademark of the Massachusetts Institute of
Technology.
MS-DOS and Microsoft are U.S. registered trademarks of Microsoft
Corporation.
OSF/Motif is a trademark of the Open Software Foundation, Inc. in the
U.S. and other countries.
First Edition: March 1995 (HP-UX Release 10.0)
==============================================================================
HP-UX 10.0 Logical Volume Manager
=================================
This paper presents a general background to the concepts of Logical
Volume Manager. Information relating to specific system administration
tasks can be found in the "HP-UX System Administration Tasks" manual.
The Logical Volume Manager (LVM) is a disk management subsystem that lets you
allocate disk space according to the specific or projected sizes of your file
systems or raw data. LVM logical volumes provide other capabilities that are
unavailable when using fixed partitions. LVM file systems can exceed the size
of a physical disk. This feature is known as disk spanning, because a single
file system can span disks. Up to three copies of identical data can be
stored and updated simultaneously using LVM. This feature is known as
mirroring, and requires an optional product, HP MirrorDisk/UX.
If you have a pre-installed HP-UX operating system (Release 9.0 or later on
S800, Release 10.0 or later on S700), LVM is ready to use.
If you want to convert non-root disks to LVM, you must back up all data from
disks, set up logical volumes on disks, and restore data to disks.
LVM is useful for managing file systems whose size is likely to grow.
With LVM, you can specify the size of a file system based on need, and
expand a file system by adding disk space from anywhere in your system.
Large-scale applications, such as databases and CAD/CAE systems,
whose data requirements often exceed the capacity of a single disk can
be expanded across disks. Disk mirroring can increase data safety and system
availability. LVM's mirroring capabilities enable you to perform some system
administration tasks, such as backups, without bringing the system down.
Disk mirroring is very valuable,but mirroring does not protect your data from
system crashes. For maximum availability of your data, eliminate all
single points of failure by mirroring your data on separate disk drives
protected by separate uninterruptable power supplies.
Disk Management Prior to HP-UX Release 10.0
Prior to the 10.0 release of HP-UX, disks were managed differently on Series
800 and Series 700 systems.
On the Series 800, disks contained pre-defined sections of fixed size, each
section appearing to the operating system as a separate disk. This
traditional built-in partitioning method is referred to as disk sectioning,
or "hard partitions". Different sections of a single disk could be used for a
boot area, file system, swap area, dump area, or raw data area.
For the 9.0 release, a second method of disk partitioning using logical
volumes was introduced on the Series 800. Using a logical volume allowed for
the combination of portions of one or more disks into a single unit.
On the Series 700, neither disk sectioning nor logical volumes were supported
in pre-10.0 releases. Instead, disks contained only a single section. Such
non-partitioned disks are also referred to as whole disks. A single disk
could contain a file system and optionally a swap area and a boot area. An
entire disk could also be used as a file system, raw data area, dump device,
or swap area.
As of the 8.07 release, disks on the Series 700 could also be managed using
Software Disk Striping (SDS). SDS distributes data across a single or
multiple disks to improve performance and also provides some of the flexible
disk partitioning found by using logical volumes. With SDS, you select
the number and size of the disk strips.
Current Disk Management
Beginning with the 10.0 release of HP-UX, disks are managed identically on
Series 800 and Series 700 systems.
On both the Series 800 and Series 700, using logical volumes is recommended
as the preferred method for managing disks.
Existing hard partitioned disks from the Series 800 and non-partitioned disks
from the Series 700 continue to be supported under release 10.0 (except for
SDS disks).
Hard partitions are only provided for models of disks that were supported
prior to release 10.0. Hard partitions will not be provided on disks
introduced with 10.0 or later.
You will not be able to use a partitioned disk for your root disk. You will
only be able to use a non-partitioned disk or LVM disk for this purpose.
Although the use of logical volumes is encouraged, disks on both the Series
800 and Series 700 can also be managed as non-partitioned disks, or with hard
partitions for those disk models that support hard partitions.
Existing disks that are non-partitioned or that have hard partitions can be
converted to use logical volumes.
Both LVM disks and non-LVM disks can exist simultaneously on your system, but
a given disk must be managed entirely by either LVM or non-LVM methods. You
cannot combine these techniques for use with a single disk.
The disk striping capabilities of Software Disk Striping on the Series 700
are no longer supported at 10.0 and have been replaced by disk striping on
logical volumes. Existing arrays of disks that made use of SDS can be
converted to use logical volumes.
You should note that although hard disk drives and disk arrays support the
use of logical volumes, floppy disks, optical disks, and CD ROMs do not.
The LVM Paradigm
Implementing LVM requires a new way of thinking about disks and file system
configurations.
In a traditional HP-UX configuration, you consider your disks individually and
in terms of their variously sized sections (or partitions), each of which
holds a file system, swap space, boot area, or raw data.
With LVM, you do not use disk sections. Instead, you consider the disks as a
pool (or volume) of data storage, consisting of equally sized (by default 4
MB) extents, multiples of which are allocated for file system, swap, and other
purposes. LVM lets you specify extent size in megabytes.
Setting up LVM requires you to follow certain procedures. These are documented
in the "HP-UX System Administration Tasks" manual.
An LVM system consists of groupings of disks initialized for LVM and organized
into volume groups. A volume group might consist of one or many LVM disks;
your entire system might consist of one or several volume groups.
While volume groups represent groupings of one or more LVM disks, logical
volumes represent subdivisions of a volume group's total disk space into
virtual disks.
Logical volumes can encompass space on one or more LVM disk and represent
only a portion of one or more LVM disks.
You apportion the disk space within a volume group when you create logical
volumes. The size of a logical volume is determined by its number of
extents, each being 4 MB by default but is configurable. You then assign
either file systems, swap, dump, or raw data to logical volumes.
For example, logical volume /dev/vg01/lvol1 might contain a file system,
logical volume /dev/vg01/lvol2 might contain swap space, and logical volume
/dev/vg01/lvol3 might contain raw data.
You can use SAM to create a file system in a logical volume of a specified
size, and then mount the file system, or by using commands, you can create and
then extend a logical volume to allocate sufficient space for file system, or
raw data. You would then create and mount new file systems or install your
application in the logical volume.
LVM Terminology
Here are some LVM terms and definitions:
Allocation Policy-- The LVM allocation policy governing how disk space is
distributed to logical volumes and how extents are laid out on an LVM disk.
LVM allocates disk space in terms of strict vs. non-strict and contiguous vs.
non-contiguous. Strict allocation requires that mirror copies reside on
different LVM disks. Contiguous allocation requires that no gaps exist between
physical extents on a single disk.
Bad Block Relocation--An LVM feature for recovering corrupted blocks of data
from HP-FL and SCSI disks, by redirecting the data to another block of media
on the disk. Bad block relocation uses a remainder of space in the disk
layout. This feature can be enabled or disabled with the lvcreate(1M) or
lvchange(1M) commands. This feature is not supported on HP-IB disks, nor is it
supported for the root logical volume.
Block-- The smallest unit of space transferable to and from a disk.
LVM transfers data in blocks of DEV_BSIZE (1024) bytes.
Extent-- Fixed-size addressable areas of space on an LVM disk or logical
volumes. On disk, these contiguous areas are called physical extents, and
are by default 4 MB. Physical extents map to areas on logical volumes, called
logical extents.
I/O Channel Separation-- A configuration of disks useful for segregating
highly I/O-intensive areas. For example, you might have a database on one
channel and file systems on another. When mirroring logical volumes using HP
MirrorDisk/UX, you can spread the mirrored copies over different I/O channels
to increase system and data availability.
Logical Volume-- A virtual storage device of flexible size that can hold a
file system (including root), raw data, dump area, or swap. Logical volumes
can be mirrored using an optional product, HP MirrorDisk/UX. Because its data
are distributed logically (rather than physically), a single logical volume
can be mapped to one LVM disk or span multiple disks. A logical volume appears
to the administrator as though it was a single disk. The lvdisplay command can
be used to verify distribution of logical volumes on actual disks.
Logical Volume Manager (LVM)-- An operating system software module that
implements virtual (logical) disks to extend, mirror, and improve the
performance of physical disk access.
LVM Disk-- A disk that has been initialized for LVM.
(Also see "physical volume.")
Mirroring-- Simultaneous replication of data (up to three copies) using an
optional product, HP MirrorDisk/UX. (HP MirrorDisk/UX is not supported on
HP-IB disks.) Duplicated information storage ensures a greater degree of data
availability. Using HP MirrorDisk/UX, LVM maps identical logical volumes to
multiple LVM disks, thus providing the means to recover easily from the loss
of one copy (or two copies in the case of double mirroring) of data. Mirroring
can provide faster access to data for applications using more data reads than
writes.
Physical Volume-- A disk that has been initialized by LVM for inclusion in a
volume group; also called an LVM disk. As with standard disks, an LVM disk
(physical volume) is accessed via a raw device file (for example,
/dev/rdsk/c3t0d0). You can use SAM or the pvcreate command to initialize a
disk as a physical volume.
Physical Volume Group-- A subset of physical volumes (LVM disks) within a
volume group, each with a separate I/O channel or interface adapter to
achieve higher availability of mirrored data.
Quorum-- The requirement that a volume group have at least half the
configured LVM disks present to change or activate that volume group. If
there is no quorum, LVM prevents the change. Quorum is checked both during
configuration changes (for example, when creating a logical volume) and at
state changes (for example, if a disk fails). If quorum is not maintained,
LVM will not acknowledge the change. Quorum ensures the consistency and
integrity of the volume groups. The vgchange command with the -q n option can
be used to override quorum check.
Root Logical Volume-- The logical volume containing the HP-UX kernel.
Synchronization-- The process of updating stale (non-current) copies of
mirrored logical extents by copying data from a fresh (current) copy of the
logical volume. Synchronization keeps mirrored logical volumes consistent by
ensuring that all copies contain the same data.
Volume group-- A collection of one or more LVM disks from which disk space may
be allocated to individual logical volumes. A disk can belong to only one
volume group. A volume group is accessed through the group file (for example,
/dev/vg01/group) in that volume group's directory. You can use SAM or the
vgcreate command to create a volume group. HP-IB devices may not be combined
with devices of any other interface in a volume group.
Using LVM Device Files
All LVM components are represented by device files located in the /dev
directory. (You might think of device files as agents for managing the
interactions with the disk space.) The LVM device files are created by both
SAM and HP-UX commands and by default follow a standard naming convention.
However, you can choose more intuitive names for volume groups and logical
volumes.
The default device file names for a LVM disk are /dev/dsk/c?t?d? for block
special files and /dev/rdsk/c?t?d? for raw special files. The default
directory name for a volume group is /dev/vg??. The default device file names
for a logical volume are /dev/vg??/lvol? for block special files and
/dev/vg??/rlvol? for raw special files.
Use a block special file to add a physical volume to a volume group or
to mount or unmount a file system. Use a raw special file to create a
physical volume.
Major and Minor Numbers of LVM Data Structures
The LVM device drivers find data via the major and minor numbers of the file
system data structures. The device file for an LVM disk is shown in the
long listing: brw-r----- 1 root sys 7 0x000302 Dec 20 15:38 /dev/dsk/c3t0d0.
The 7 represents the major number.
Now compare the following minor numbers (such as 0x030000) for a volume group:
crw-rw-rw- 1 root other 64 {{0x030000}} Jan 23 14:35 group
brw-r----- 1 root other 64 {{0x030001}} Jan 24 17:02 lvol1
crw-r----- 1 root other 64 {{0x030001}} Jan 24 17:02 rlvol1
brw-r----- 1 root other 64 {{0x030002}} Feb 3 11:53 lvol2
crw-r----- 1 root other 64 {{0x030002}} Feb 3 11:53 rlvol2
brw-r----- 1 root other 64 {{0x030003}} Mar 6 12:01 sales
crw-r----- 1 root other 64 {{0x030003}} Mar 6 12:01 rsales
They were created using the following format:
31 23 15 7 0
+------------+---------+--------+---------+
|major number|VG number|reserved|LV number|
+------------+---------+--------+---------+
|<-------minor number------->|
The logical volume (LV) number is encoded into bits 0-7; the volume group
number (03) is encoded into bits 16-23. The major number is encoded into bits
24-31. Note too, the block and raw special files created for the logical
volume /dev/vg00/sales.
Within each volume group directory is a special file, group, with the volume
group major number 64, logical volume number 0, and volume group number.
By default, volume group numbering begins with zero (vg00), while logical
volumes begin with one (lvol1). This is because the logical volume number
corresponds to the minor number and the volume group's group file is assigned
minor number 0.
HP-UX accommodates up to 256 volume groups and 255 logical volumes per volume
group.
Understanding Volume Groups
If you install LVM on your root file system, you have /dev/vg00, your first
LVM volume group. (If you have not installed LVM on your root file system,
you must use SAM or manually create /dev/vg00.) You can then apportion disk
space from the volume group into logical volumes.
As we have seen, volume groups are visible in HP-UX as device files in the
/dev directory. The directory includes device files for the logical volumes
belonging to the volume group. The volume group directory also contains a
group file, which provides LVM data structures with information about the
entire volume group. (These data structures are described in "Characteristics
and Layouts of LVM Disks", later in this chapter.)
To see the contents of a volume group, run the vgdisplay command. See
vgdisplay(1M) in the "HP-UX Reference Manual" for full explanation of the
command and its options.
The verbose output of vgdisplay on a system comprised of one volume group, one
LVM disk (physical volume), and two logical volumes is shown below. You can
also see that volume group /dev/vg00 consists of one physical volume (PV) out
of a maximum 32, two logical volumes (LV) out of a maximum 255, and that each
physical extent (PE) is four megabytes. Of a total 632 physical extents
available, 170 have been allocated, leaving 462 free. Status information
reveals that the logical volume contents are synchronized, or up-to-date.
% vgdisplay -v
--- Volume groups ---
VG Name /dev/vg00
VG Status available
Max LV 255
Cur LV 2
Open LV 2
Max PV 32
Cur PV 1
Act PV 1
PE Size (MB) 4
Max PE per PV 1016
VGDA 2
Total PE 632
Alloc PE 170
Free PE 462
Total PVG 0
--- Logical volumes ---
LV Name /dev/vg00/lvol1
LV Status available/syncd
Current LE 10
Allocated PE 10
Used PV 1
LV Name /dev/vg00/lvol2
LV Status available/syncd
Current LE 20
Allocated PE 20
Used PV 1
--- Physical volumes ---
PV Name /dev/dsk/c2t0d0
PV Status available
Total PE 632
Free PE 462
HP-IB Limitations
HP-IP disks must be used in their own volume group and cannot be
combined in volume groups with HP-FL or SCSI disks. This is because
HP-IB disks can handle only limited LVM capabilities: HP-IB does not
support bad block relocation or disk mirroring.
Consider newfs Limitations when Organizing Volume Groups
Best system performance is achieved if you organize your volume groups by
identical disk type. This means that if you create a file system that spans
LVM disks, be sure that the logical volume in which the file system resides
spans identical disk types.
This guideline derives from the behavior of newfs(1M): when you run the newfs
command to construct a file system, you can specify only one disk type, which
newfs then uses to lay out the disk. If more than one disk type is used for
the file system, the logical volumes on the specified disk type will perform
well, but the unspecified disk type will undoubtedly be less efficient. Thus,
try to maintain consistency of disk type among physical volumes used for any
logical volume that holds a file system.
You might already know the disk type to which your file system is being
mounted. However, on a system set up with LVM, the lvdisplay -v command is
the most accurate starting point for finding the correct disk type.
Another consideration when grouping disk drives is their relative size: The
size of disk drives within a volume group should be similar (within a factor
of two between largest and smallest) to avoid wasting space on LVM data
structures.
Consult /usr/sbin/diskinfo for Disk Attributes
When setting up logical volumes, you might find the information presented by
/usr/sbin/diskinfo helpful in determining how to allocate your file systems.
The /usr/sbin/diskinfo command describes disks attributes such as number of
bytes per sector, device type, and timing information. You can also use it
for more information about a device file listed in /etc/fstab. The following
example shows relevant output from /usr/sbin/diskinfo for a SCSI disk:
# /usr/sbin/diskinfo -v /dev/rdsk/c3t0d0
SCSI describe of /dev/rdsk/c3t0d0:
vendor: HP
product id: 2213A
type: direct access
size: 648192 Kbytes
bytes per sector: 512
blocks per disk: 1296511
The Root Volume Group
In a traditional configuration, the root disk contains all the attributes
required for initial booting, plus system files, dump, and primary swap --
all on one disk. In LVM, the concept of a single root disk is replaced by a
root volume group. The root volume group contains all the same elements as a
root disk, and /, swap, and /usr. The root volume group can be more than one
disk, but the root logical volume can be only on one disk. In practice,
however, your root volume group might be nearly identical to a traditional
root disk. By default, the HP-UX installations programs automatically fill
one disk at a time. You can mirror root logical volumes, using an optional
product, MirrorDisk/UX.
When you install the system, having decided to implement LVM, the migration
and installation processes set various options ensuring that your root volume
group is properly configured. Later, if you choose to establish another root
volume group, you might want to refer to the guidelines found in "Guidelines
for Configuring the Root Volume Group", later in this text.
Underlying the root volume group is an LVM disk data structure different from
that of non-bootable LVM disks. Bootable LVM disks have sectors reserved for
a boot data reserved area (BDRA) and a LIF volume containing boot programs.
For an LVM disk to be bootable, it must be initialized using the pvcreate(1M)
command with the -B option (see "Managing Disks Using the Logical Volume
Manager (LVM)" in the "HP-UX System Administration Tasks" manual for the
procedure.) The boot data reserved area and characteristics common to both
bootable and standard physical volumes are discussed later in this text, in
"Characteristics and Layout of LVM Disks".
Contiguous vs. Non-Contiguous Allocation of LVM Disk Space
Just as traditional disk space is allocated contiguously if possible, and
then by fragments, for efficient use of disk space, so LVM allocates disk
space with regard to contiguity.
Contiguous disk space allocation means that the logical extents (LE) of a
logical volume must be mapped to adjacent physical extents (PE) on an LVM
disk. Non-contiguous disk space allocation means that the logical extents of
a logical volume need not be mapped to adjacent physical extents.
Disk space used by the root logical volume must be contiguous. That is,
physical extents mapping to the logical volumes of the root file system,
primary swap, and dump must each be contiguous. Contiguous extents also
adhere to the following requirements: physical extents must be allocated in
ascending order, no gap may exist between physical extents, and when
mirrored, all physical extents of a mirrored copy must reside on the same LVM
disk.
Contiguous allocation is less flexible than non-contiguous allocation, and
therefore uses disk space less economically. Non-contiguous mapping can
result in a logical volume's physical extents being dispersed onto more than
one LVM disk, since logical volumes can span multiple disks.
Understanding Logical Volumes
Logical volumes are allotments of disk space made from a volume group. Like
disk sections or partitions, logical volumes hold file systems, swap, dump,
or raw data; unlike disk sections, you can set the capacity of logical
volumes according to your need.
Logical volumes consist of logical extents, which map to the physical extents
of LVM disks. This mapping gives logical volumes great flexibility: to span
more than one LVM disk, to be larger than a single LVM disk, to be reduced or
expanded to meet changing file system needs, and to be mirrored using HP
MirrorDisk/UX.
Each logical volume has a block special device file and raw special device
file. These device files are listed in the subdirectory of the volume group
to which the logical volumes belong.
To see information about a logical volume, type the lvdisplay command, giving
as the argument the pathname of the logical volume. You will see something
like the following:
% lvdisplay /dev/vg00/lvol1
--- Logical volumes ---
LV Name /dev/vg00/lvol1
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
Current LE 10
Allocated PE 10
Bad block on
Allocation strict
Much of the information given -- LV status, Mirror copies, Consistency
Recovery, Schedule, bad block, and Allocation -- pertain to mirroring
capabilities provided by the optional product, HP MirrorDisk/UX. Mirroring
is described later in this text.
Verbose output of the lvdisplay command shows the mapping of physical extents
(PE) and logical extents (LE) of the logical volume on the LVM disk. This
information can be useful when creating a file system.
The following display shows logical extents.
--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c2t0d0 10 10
--- Logical extents ---
LE PV1 PE1 Status 1
0000 /dev/dsk/c2t0d0 0000 current
0001 /dev/dsk/c2t0d0 0001 current
0002 /dev/dsk/c2t0d0 0002 current
0003 /dev/dsk/c2t0d0 0003 current
0004 /dev/dsk/c2t0d0 0004 current
0005 /dev/dsk/c2t0d0 0005 current
0006 /dev/dsk/c2t0d0 0006 current
0007 /dev/dsk/c2t0d0 0007 current
0008 /dev/dsk/c2t0d0 0008 current
0009 /dev/dsk/c2t0d0 0009 current
Allocating Disk Space for Logical Volumes
Using traditional S800 HP-UX, once you partition the disk into fixed disk
sections of various sizes, you make your file systems in the context of these
sections. Supported section sizes are shown in /etc/disktab. Using LVM, you
create a logical volume and allocate disk space for file systems, swap, dump,
or raw data in either megabytes or an LVM unit of measure called an extent.
By default, LVM extents are 4 MB. Extent size is configurable, provided the
size chosen is a power of two (for example, 1,2,4,8); valid extents can range
in size from 1 MB to 256 MB.
When calculating the size of a logical volume to contain a file system, base
your calculations on how many megabytes a file system needs, but choose a
quantity divisible by the extent size. Any quantity not divisible by extent
size is rounded up.
Under most circumstances, you need never change the 4-MB default extent size.
Exceptions might arise for extremely large disks. Large extents are more
wasteful of disk space and smaller extent sizes allow a finer granularity of
allocation. (For more information on these considerations, see "Volume
Group Descriptor Area (VGDA)", later in this text.)
Logical volumes consist of logical extents mapped to physical extents.
The mapping is 1 to 1 for non-mirrored disks, 1 to 2 for singe-mirrored
disks, and 1 to 3 for double-mirrored disks.
LVM uses one or more kinds of extents. LVM stores data on disks as sets of
addressable, disk blocks called physical extents. Logical volumes consist of
logical extents, which map to the disks' physical extents.
An unmirrored logical volume has an identical number of physical and logical
extents; a doubly mirrored logical volume has three physical extents to each
logical extent.
Logical extents can be mapped non-contiguously to physical extents on LVM
disks. This means that LVM can disperse data in non-consecutive physical
extents on disk. An exception to this policy is the root logical volume.
(See "Contiguous vs. Non-Contiguous Allocation of LVM Disk Space", earlier in
this text.)
How LVM Maps Extents to Logical Volumes
The LVM subsystem maps logical extents to physical extents via a translation
table that resides on the LVM disk. When the volume group is activated, the
table resides in real memory. LVM translates incoming read and write
requests to the correct address of the physical extent, then sends the request
to the corresponding physical block. Thus, the extent serves as a translation
mechanism between the incoming request and underlying device drivers.
By default, LVM selects available physical extents from LVM disks in the order
the disks were added to the volume group.
The physical-to-logical extent mapping of a logical volume can be
discontiguous; a single logical volume (and therefore file system) can exist
on several different LVM disks or on noncontiguous regions of the same disk.
File system performance is best, however, when its physical extents are
contiguous, whether on one or multiple LVM disks.
As a system administrator, you can control to which LVM disks a logical
volume is mapped (bypassing the default LVM's distribution), by using a
two-step process of lvcreate and lvextend. This is documented in the "HP-UX
System Administration Tasks" manual, "Managing Disks Using the LVM."
LVM Disk Space Allocation Commands
You can use SAM or the vgcreate(1M) command to set the size and number of
physical extents in a volume group. You can use SAM or the lvcreate(1M)
command to assign the number of physical extents in a logical volume. You can
increase the number of logical extents in a logical volume by using the
lvextend(1M) command. You can display the size (in bytes) of physical extents
(PE) in a volume group by using the vgdisplay(1M) command. You can display the
number of logical extents (LE) in a logical volume by using the lvdisplay(1M)
command.
Understanding Physical Volumes (LVM Disks)
Physical volumes (also called LVM disks) are disks that have been initialized
(using SAM or pvcreate) for LVM. Whereas traditional disks are pre-defined as
partitioned into sections (S800), or contained in a single section (S700).
Space on LVM disks is allocated for logical volumes by the administrator.
Physical volumes use the same device special files as traditional HP-UX disk
devices. Once a disk has been initialized, you can view its characteristics
as an LVM disk by running the pvdisplay command, giving as an argument the
disk's block special file.
The output from pvdisplay might look like the following:
% pvdisplay /dev/dsk/c2t0d0
--- Physical volumes ---
PV Name /dev/dsk/c2t0d0
VG Name /dev/vg00
PV Status available
Allocatable yes
VGDA 2
Cur LV 4
PE Size (MB) 4
Total PE 632
Free PE 462
Allocated PE 170
Stale PE 0
A verbose listing (pvdisplay -v) of the same LVM disk shows the mapping
status of all available physical extents. (In the following example, physical
extents 0170 to the end are free, meaning unallocated.)
--- Distribution of physical volume ---
LV Name LE of LV PE for LV
/dev/vg00/lvol1 10 10
/dev/vg00/lvol2 20 20
/dev/vg00/lvol3 100 100
/dev/vg00/lvol4 40 40
--- Physical extents ---
PE Status LV LE
0000 current /dev/vg00/lvol1 0000
0001 current /dev/vg00/lvol1 0001
0002 current /dev/vg00/lvol1 0002
0003 current /dev/vg00/lvol1 0003
.
.
.
0170 free 0000
0171 free 0000
0172 free 0000
.
.
.
Sector Size of Physical Volumes (LVM Disks)
In HP-UX, different disk types have different sector sizes. HP-IB and HP-FL
disks have 256 bytes per sector; SCSI disks have 512 bytes per sector;
multi-spindle disk arrays have 2048 bytes per sector. LVM deals with this
diversity without user intervention.
The disk device drivers (such as disc3 for SCSI) understand the language of
the physical disk as well as a requirement of HP-UX, which specifies that
device drivers be able to receive data in units of DEV_BSIZE (1024) bytes and
pass the data to the disk in its own terms.
When using the raw interface to a device (as with a database application),
data are read and written in DEV_BSIZE units. This can pose a performance
loss for multi-spindle disk arrays, whose writes are required in units of 2
KB, the disk array's underlying sector size. For example, to transfer 1 KB
(that is, one DEV_BSIZE unit) of data, the controlling device driver reads in
2 KB of data (even though only 1 KB is changing) in order to write in the 2-KB
sector size required by the disk array. (This is called "read modify write.")
For block interface (as with a file system), there is no performance loss as
long as the fragment size is 2 KB or greater.
Any file system that resides, even partially, on a multi-spindle disk array
should have its fragment size be a multiple of 2 KB.
LVM handles all data transfers in terms of DEV_BSIZE units. In most cases,
LVM communicates with the disk driver directly, to ensure that I/O block size
is a multiple of DEV_BSIZE and the beginning I/O address begin on the
DEV_BSIZE boundary. LVM allocates disk space in units of extents. Extent
sizes range from 1 MB to 256 MB and must be a power of 2.
Characteristics and Layout of LVM Disks
There are two kinds of LVM disk layouts -- for boot disks and all other LVM
disks -- and they differ in their data structures. Non-bootable disks have
two reserved areas -- the physical volume reserved area (PVRA) and the volume
group reserved area (VGRA), while bootable disks have additional sectors
reserved for the boot data reserved area (BDRA) and LIF.
Boot Data Reserved Area (BDRA)
To boot the system, the kernel activates the volume group to which the
system's root logical volume belongs. The location of the root logical volume
is stored in the boot data reserved area (BDRA). The boot data reserved area
contains the locations and sizes of LVM disks in the root volume group and
other vital information to configure the root, primary swap, and dump logical
volumes, and to mount the root file system.
The BDRA contains the following records about the system's root logical
volumes: timestamp (indicating when the BDRA was last written), checksum for
validating data, root volume group ID, the number of LVM disks in the root
volume group, a list of the hardware addresses of the LVM disks in the root
volume group, indices into that list for finding root, swap, and dump, and
information needed to select the correct logical volumes for root, primary
swap, and dumps.
Information about the LVM disk data structures in the BDRA is maintained by
using the lvlnboot(1M) and lvrmboot(1M) commands. Here is sample output,
followed by explanation:
# ./lvlnboot -v -d /dev/vg00/lvol2
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c3t0d0 -- Boot Disk
/dev/dsk/c4t0d0 -- Boot Disk
/dev/dsk/c5t0d0
/dev/dsk/c12t0d0 -- Boot Disk
Root: lvol1 on: /dev/dsk/c3t0d0
/dev/dsk/c4t0d0
Swap: lvol2 on: /dev/dsk/c3t0d0
/dev/dsk/c4t0d0
Dump: lvol2 on: /dev/dsk/c3t0d0
The physical volumes (LVM disks) designated "Boot Disk" are bootable, having
been initialized with mkboot and pvcreate -B. Multiple lines for lvol1 and
lvol2 reveal that the root and swap logical volumes are being mirrored.
Notice that lvol2 is being used for both swap and dump, but that mirroring
applies to only swap.
LIF Information
Much like non-LVM boot disks, the LVM boot disk contains a LIF volume, in
which are stored ISL, HPUX, AUTO, IOMAP, RDB, and LABEL.
The LIF LABEL file is created and maintained by lvlnboot and lvrmboot. The
LABEL file has pointers to the starting point and size of boot-relevant
logical volumes, including the file system containing the kernel. The support
and install tapes use the information to access the root, primary swap, and
dump logical volumes without actually using LVM.
If the LIF or any reserved area becomes corrupted, the support tape can be
used to recover the operating system. If that fails, or is impractical, the
system must be re-installed.
The LIF volume cannot be copied directly onto LVM disk using dd(1M). It must
be set up by the install process or by mkboot(1M) on LVM disks for which the
pvcreate -B option was used, due to a gap between the LIF header and LIF
directory.
Physical Volume Reserved Area (PVRA)
Everything LVM needs to know about an LVM disk is contained in the physical
volume reserved area (PVRA). The physical volume reserved area stores
information about the LVM disk configuration and operation, starting
addresses, and sizes. It also contains a bad block directory for the LVM disk.
The PVRA contains the following record of the LVM disk in relation to its
volume group: LVM identification field (signifying that the LVM record is
present and valid), unique physical volume ID (checked by the LVM when it
generates new physical volumes), physical volume number within the volume
group, last physical sector number (used in determining the amount of space
available on the disk), size of each physical extent on the LVM disk
(expressed exponentially in DEV_BSIZE blocks with all physical extents
identical in size for all disks in a volume group), and the amount of space
(expressed in number of DEV_BSIZE blocks) allocated for each physical extent
on the LVM disk.
The PVRA also contains the starting addresses (physical sector number and
length) of the following areas: Boot Data Reserved Area (for boot volume
groups), Volume Group Reserved Area, Volume Group Descriptor Area, Volume
Group Status Area, Mirror Consistency Records, User Data Area, and the Bad
Sector Relocation Pool.
The bad block directory of the PVRA contains a record of all software sectors
that are faulty, have been relocated, or are awaiting relocation.
Hardware sectors are not included.
Volume Group Reserved Area (VGRA)
The volume group reserved area (VGRA) describes the volume group to which the
disk belongs. This information is organized in three subareas: Volume Group
Descriptor Area (VGDA), Volume Group Status Area (VGSA), and the Mirror
Consistency Record.
Volume Group Descriptor Area (VGDA)
The volume group descriptor area (VGDA) contains the information the LVM
device driver needs to configure the volume group for LVM, including the
volume group header, a list of logical volume entries, a list of LVM disks,
and the volume group trailer.
The volume group header, with timestamp, indicates when the VGDA was last
updated, the volume group ID number, and three configurable operating system
parameters: maxlvs-- maximum number of logical volumes allowed per volume
group, maxpxs-- maximum number of physical extents allowed per LVM disk,
and maxpvs-- number of LVM disks that can be installed in the volume group.
The list of logical volume entries, one for each logical volume within the
volume group, recorded the maximum number of logical extents permissible per
logical volume, the current status and capabilities of the logical volume,
the mirroring schedule policy, if set, and the maximum number of mirror copies
allocated, if set.
The list of LVM disks includes: the header with global information (ID, number
of physical extents, status) about the disk, and the map of physical extents
to logical volumes.
The volume group trailer is timestamped when the VGDA was last updated. (Both
the header and trailer timestamps are compared to verify the consistency of
the VGDA.)
The VGDA is the area checked to ensure a quorum of total LVM disks in the
volume group. The VGDA is replicated on all of the physical volumes and
updated whenever a configuration change is made. A volume group cannot be
activated unless half the disks in a volume group are present and available,
that is, containing the latest state information. A quorum of > 51% is
required for the system to boot, and a quorum of 50% or greater is required
for LVM to run. The vgchange -q n option can be used to override the system's
quorum check.
Overriding quorum can result in a volume group whose configuration is
inaccurate (for example, missing recently creating logical volumes). This
configuration change might not be reversible.
Since each physical extent is recorded in a VGDA entry, the extent size has a
direct bearing on the VGDA. In most cases, the default extent size will work
perfectly well. However, if you run into problems, you might consider that
the VGDA is a fixed size and a high-capacity LVM disk might exceed the total
number of physical extents allowed. As a result, you might need to use a
larger-than-default extent size on high-capacity LVM disks. Conversely, if all
LVM disks in a volume group are small, the default number of extents might
make the VGDA too large, wasting disk and memory space. A smaller-than-default
extent size or number of physical extents might be preferable. A high-capacity
LVM disk might be unusable in a volume group whose extent size is small or set
with a small number of physical extents per disk.
Volume Group Status Area (VGSA)
The volume group status area (VGSA) tracks the validity and availability of
LVM disks and the current state of physical extents (stale or fresh). The LVM
reads this information when it initializes the volume group, updates it as a
result of configuration changes to the volume group, or as a result of I/O
errors.
The VGSA can be considered an extension of the VGDA, because it duplicates
some of VGDA information, such as quorum, maxpvs, and maxpxs.
Mirror Consistency Record (MCR)
When the Mirror Write Cache is used, the mirror consistency record (MCR)
minimizes the amount of I/O required to bring all mirrors into a consistent
state following a system crash or power failure. The cache consists of a
list of active transactions used to synchronize the disks at boot and
therefore provides faster system boot.
The MCR contains records of: the timestamp when the mirror consistency record
was last written, the minor numbers of the logical volumes involved, and the
number and size of the logical track group to which the logical volume is
associated.
User Data Area
The user data area is the region of the LVM disk used to store all user data,
including file systems, virtual memory system (swap), or user applications.
When you create the logical volume, you apportion the user data area into
fixed-size physical extents. Physical extents map to logical extents that hold
user data -- file systems, virtual memory subsystem, or a user application.
By default, physical extent size is 4 MB. On high-capacity LVM disks, the
default limit on the total number of physical extents per LVM disk might
necessitate a larger extent size, or a larger number of physical extents per
LVM disk.
Bad Block Relocation Policy
Bad blocks can cause serious data transfer problems. The LVM device driver
checks each physical request for bad blocks in the address range of the
request. If it encounters a bad block on a mirrored LVM disk, LVM can recover
from the error by reassigning the data to other blocks on the disk. This
feature, called bad block relocation, is enabled by default.
With this feature, LVM supports two types of bad block relocation: soft
relocation, which assigns a new block to replace the defective one, and hard
relocation, in which LVM instructs the disk device driver to spare the bad
sector(s).
The following commands deal with LVM bad block relocation policy: lvcreate(1M)
which sets bad block relocation policy for logical volumes being created in a
given volume group, lvchange(1M) which allows you to change the policy to
prevent or allow bad block relocation for logical volumes in a given volume
group, and pvcreate(1M) which lets you specify the minimum number of bad
blocks that LVM should reserve to perform software bad block relocation. (By
default, one block for every 8K of data blocks is reserved.)
It is always a good practice to run diagnostics testing for bad blocks on any
device before initializing an LVM disk.
LVM Overhead
The data structures that enable you to use LVM consume a modest amount of
overhead from your disk space. This overhead is set at a fixed boundary
(2912 KB) for bootable LVM disks and may vary in size in non-bootable LVM
disks (typically 400 KB).
Overhead required by non-bootable LVM disks depends on the LVM parameters
which can be modified using SAM or the vgcreate command. If you set a small
extent size or create many physical volumes, your LVM data structures
(overhead) will be larger. Option -e sets the maximum number of physical
extents allocatable for LVM disks in a volume group (by default, 1016).
Option -l sets the maximum number of logical volumes allowed in a volume group
(by default, 255). Option -p sets the maximum number of LVM disks (physical
volumes) allowed in a volume group (by default, 32). Option -s sets the size,
in megabytes, for each physical extent in a volume group (by default, 4).
An operating-system parameter, maxvgs, can be configured to set the maximum
number of volume groups LVM will recognize. Its default is 10 it and can be
overridden. The permissible range is 0 to 256.
Understanding LVM Configuration Maintenance
While LVM provides desirable flexibility on your HP-UX system, it also adds a
level of complexity for system administration. Be sure that you safeguard your
LVM configuration by backing it up.
Guidelines for Configuring the Root Volume Group
The following options are recommended when setting up the root logical volume
using the lvcreate(1M) command. The same conditions can be applied when using
SAM: -C y makes extents contiguous, and -r n turns off bad block relocation.
For any swap logical volume, the following options should be used: -C y makes
extents contiguous, -M n turns off the Mirror Write Cache (used for
mirroring), and -c n turns off all synchronization.
A dump logical volume requires only -C y as a special options, as long as
it is not also a swap logical volume, in which case it requires the same
options as swap. -C y makes extents contiguous.
The /etc/lvmtab File
At the heart of the LVM configuration is the /etc/lvmtab file, which is read
by all LVM commands. /etc/lvmtab is not readable or editable on-screen.
The /etc/lvmtab file is run-time generated; that is, it is generated the
first time you create an LVM entity using SAM or commands such as vgcreate,
and updated every time you change the LVM configuration. Every configuration
update or query reads the /etc/lvmtab file.
LVM disk file names are recorded in /etc/lvmtab. If /etc/lvmtab file is
destroyed, all configuration operations involving LVM data structures become
impossible.
You can recover the /etc/lvmtab file using vgscan.
vgcfgbackup and vgcfgrestore back up and restore only the LVM configuration,
not the user data the LVM data structures contain. You still have to back up
and restore user data using HP-UX utilities, such as fbackup and frestore.
The vgcfgbackup command backs up volume-group configuration information into
binary files, one file per volume group.
The vgcfgrestore command restores LVM disk configuration in case of disk
loss or data corruption.
vgcfgbackup backs up the LVM record of each LVM disk, the BDRA record for
each bootable LVM disk, one copy each of the current VGDA and VGSA data
structures, and LIF LABEL files.
vgcfgbackup does not back up LIF header and files, nor bad block directory.
A command useful in maintaining the /etc/lvmtab file is vgscan(1M). If
/etc/lvmtab is deleted or corrupted, running vgscan recreates the /etc/lvmtab
file. vgscan searches every LVM disk on the system for logical volumes, then
groups them into volume groups by searching the /dev directory and matching
major and minor numbers.
Dealing with Removable Media and Volume Groups
Before a volume group created on another computer system can be accessed, the
volume group must be associated with its new system by being written into
/etc/lvmtab. It is a good idea to group your physical volumes into volume
groups that you can move as a single disk. Two commands, vgexport(1M) and
vgimport(1M) deal with these circumstances.
The vgexport command removes the definition of a volume group from the system
(/etc/lvmtab and device files) without removing it from the disks. This
allows the disks to be brought to another system and used there (after you
execute vgimport).
The vgimport command scans a specified list of LVM disks, rebuilds volume
group information, updates /etc/lvmtab, and sets up LVM special files for the
new volume group.
LVM Maintenance Mode
Maintenance mode boot provides a means, during system installation, or when
critical LVM data structures have been lost, to boot from an LVM disk without
the LVM data structures.
After the support media included in the HP-UX product kit has made the LVM
disk minimally bootable, the system can be booted in maintenance mode using
the -lm option to the hpux command at the ISL> prompt. This causes the system
to boot to single-user mode without primary swap, dump, or LVM to access the
root file system.
For further information, refer to hpux(1M) in the "HP-UX Reference
Manual".
The system must not be brought to multi-user mode (that is, init 2) when in
LVM maintenance mode. Corruption of the root file system might result.
Mirroring
Mirroring requires the optional product, HP MirrorDisk/UX. Mirroring is not
available on HP-IB disks. Mirroring is the capability of storing identical
copies of data in logical volumes, preferably on separate disks.
This redundancy has several advantages: the system can survive LVM disk
crashes if you mirror the root file system and swap, valuable data is
available on more than one LVM disk thus providing high availability. If an
I/O channel fails, LVM can recover the data from the duplicate source.
Mirror-write recovery mechanisms enable the system to synchronize data.
Mirroring speeds read-intensive applications by enabling the hardware to read
data from the most convenient LVM disk thus optimizing I/O. Backups can be
done on one copy of the data while another copy continues to run. And,
mirroring of data to areas of the same LVM disk allows you to overcome local
media errors although this procedure is not recommended.
Single mirroring occurs when data are mapped from one logical extent to two
sets of physical extents on LVM disks. Double mirroring maps each logical
extent to three sets of physical extents on LVM disks. (Sets of logical
extents can map strictly to separate LVM disks or non-strictly to different
areas of the same disk although this is not recommended.)
Each copy of mirrored data maps to the same logical volume; the number of
logical extents remains constant, but the number of used physical extents
(and therefore, occupied disk space) changes, depending on the number of
mirrored copies.
Mirrored logical volumes must belong to the same volume group; you cannot
mirror across volume groups.
I/O Channel Separation
I/O channel separation is an approach to LVM configuration requiring that
mirrored copies of data reside on LVM disks accessed via separate device
adapters (interface cards) and cables. I/O channel separation achieves higher
availability and better performance by reducing the number of single points
of possible hardware failure. If you mirror data on two separate disks, but
through one card, you are vulnerable to failure if the card fails.
You can separate I/O channels on a system with multiple disk adapters, and
with a single bus, by mirroring disks across different interface cards.
You can further ensure channel separation by establishing a policy called
PVG-strict allocation, which requires logical extents to be mirrored in
separate physical volume groups. Physical volume groups are subgroups of LVM
disks (physical volumes) within a volume group.
An ASCII file, /etc/lvmpvg contains all the mapping information for the
physical volume group, but the mapping is not recorded on disk. Physical
volume groups have no fixed naming convention; you might name them PVG0, PVG1,
and so on. The /etc/lvmpvg file is created and updated using the vgcreate,
vgextend, and vgreduce commands.
I/O channel separation is particularly useful for databases, because it
heightens availability (LVM has more flexibility in reading data on the most
accessible logical extent), resulting in better performance. If you define
your physical volume groups to span I/O devices, you ensure against data loss,
even if one card fails.
For best performance, group the LVM disks by type (for example, all HP-FL or
all SCSI). When using physical volume groups, you might also want to use a
strictly PVG allocation policy for logical volumes.
As with other mirroring features, physical volume groups are not supported on
HP-IB.
How Mirrored Logical Volumes are Written
Three sets of policies govern how mirrored logical extents are written to
physical extents: allocation policy, scheduling of disk writes, and
synchronization policy for crash recovery.
Allocation, scheduling, and synchronization can be set using SAM,
lvcreate(1M), or lvchange(1M).
Allocation Policies for Mirroring
Mirrored data can be distributed on LVM disks by strict or non-strict,
contiguous or non-contiguous allocation. By default, allocation of mirrored
logical volumes is set to strict, non-contiguous.
Strict allocation requires logical extents to be mirrored to physical extents
on different LVM disks. Non-strict mirroring allows logical extents to be
mirrored to sets of physical extents, not necessarily on different LVM disks.
Contiguous allocation policy has three characteristics: physical extents are
allocated in ascending order, no gap exists between physical extents within a
mirror copy, and all physical extents of a mirror copy reside in a single LVM
disk. Non-contiguous allocation allows logical extents to be mapped to
non-consecutive physical extents.
When the logical volumes allocated from the root volume group are mirrored,
each must be set up with contiguous extents. That is, the physical extents
used by logical volumes for root, primary swap, or dump devices must be
consecutive for each mirrored copy.
Scheduling Policies for Disk Writes
The LVM scheduler converts logical requests into one or more physical
requests, then schedules them through the physical layer. Scheduling occurs
for both mirrored and non-mirrored data.
To ensure maximum control, three I/O schedule policies are available --
parallel, sequential, and dynamic.
The parallel scheduling policy is used by default with mirroring for maximum
I/O performance. Parallel scheduling causes mirror operations to write
simultaneously to all copies. LVM performs reads in an optimized fashion, by
reading from the LVM disk with the fewest outstanding I/O operations.
The sequential scheduling policy causes mirror write operations to proceed
sequentially; that is, one write completes before the next write begins.
Likewise, LVM mirrors are read in a predefined order. On a practical level,
sequential policy would be used only for extreme caution in maintaining
consistency of mirrors.
The dynamic scheduling policy allows the writing of mirror copies to be
determined at the time of processing. If the write is synchronous, meaning
that file system activity must complete before the process is allowed to
continue, parallel writes are used, allowing quicker response time. If the
write is asynchronous, meaning that the write does not need to complete
immediately, sequential writes are selected.
Synchronization Policies for Recovering Mirrored Data
Maintaining consistency of mirrored data can be accomplished by configuring
your system using any of three different approaches: mirroring with the
Mirror Write Cache enabled, mirroring with the Mirror Write Cache disabled
and LVM Mirror Consistency Recovery enabled, and mirroring without using an
LVM mirror consistency mechanism.
The Mirror Write Cache provides a fast resynchronization of data following
a system crash or failure, but at a potential performance cost for routine
system use.
The Mirror Write Cache keeps track of all available space on the LVM disk
to which you are writing, periodically recording the activity in an on-disk
data structure called the Mirror Write Consistency Record. An extra disk write
is required for every mirrored write not already marked on the LVM disk. This
slows down on-line processing and degrades performance when you access the
disk at random; when writing to an area of the disk that is already marked,
performance is not impaired. Upon system reboot after crash, the operating
system uses the relatively small record of the Mirror Write Cache to
resynchronize inconsistent data blocks quickly.
The frequency of extra disk writes is small for sequentially accessed logical
volumes (such as database logs), but increases when access is more random.
Therefore, logical volumes containing database data or file systems with few
or infrequently written large files (greater than 256 KB) should not use the
Mirror Write Cache when run-time performance is more important than
crash-recovery time.
When mirroring with the Mirror Write Cache is disabled and LVM Mirror
Consistency Recovery is enabled, LVM does not impact run-time I/O performance.
However, for any logical volumes using Mirror Consistency Recovery, the
entire data space is resynchronized when the volume group is activated.
Synchronization is performed in the background without interfering with reboot
or access; however, during this time, I/O performance is degraded.
When mirroring without using any LVM mirror consistency mechanism, the
operating system's run-time behavior is identical to that of the previous
approach. This approach is useful when running an application program (such
as a database) that has its own means of maintaining or recovering consistent
data, such as transaction logfiles. Note, however, that the database logfiles
themselves can be configured as a mirrored logical volume to use effectively
the Mirror Write Cache.
Manual Synchronization
An HP-UX command, lvsync(1M), can be used to manually refresh extents that
have been marked "stale." This approach recovers "stale" extents by reading
from a "current" mirrored physical extent and writing to the "stale" physical
extent.
Backing Up Mirrored Data
Backups can be performed on one copy of an off-line logical volume, while
another copy is operational. This is done using the lvsplit command to take a
mirrored logical volume off-line, backing it up, then using lvmerge to return
the backup copy of the logical volume on-line. Double mirroring (mirroring
onto three LVM disks) enables you to continue mirroring while performing the
backup. (This is especially useful for high availability environments.)
Useful Mirroring Commands
Although you can perform all mirroring tasks using SAM, the commands listed
below can also be used in a mirrored environment. Their manual pages, in
"HP-UX Reference", provide further information about LVM capabilities.
lvcreate(1M) creates a logical volume in a volume group, at which time you can
set the scheduling policy, set the number of mirror copies, enable or disable
the Mirror Write Cache, and enable or disable the LVM Mirror Consistency
Recovery mechanism.
lvchange(1M) changes the characteristics of a logical volume. This includes
scheduling policy, enabling or disabling the Mirror Write Cache, enabling or
disabling the Mirror Consistency Recovery mechanism.
lvextend(1M) increases the number of physical extents allocated to a logical
volume.
lvdisplay(1M) shows information about logical volumes, including the mode set
for mirror consistency recovery and scheduling policy.
lvsync(1M) synchronizes physical extents that are stale in one or more
mirrored logical volumes.
vgchange(1M) allows changes to characteristics of the volume group.
lvsplit(1M) divides a mirrored logical volume into two logical volumes.
lvmerge(1M) combine two logical volumes into one logical volume.
Internal Representation of LVM
The LVM pseudo-device driver (lv) handles all I/O operations for the LVM
components on behalf of applications, file systems, and other subsystems.
System management commands perform LVM configuration operations by opening
the volume group's control device and issuing LVM ioctl calls. When
applications issue open, read, write, ioctl, and close calls, the top half of
lv does everything required to send a request to the underlying disk drivers.
This includes ensuring that requests do not overlap, choosing how to access
the mirrors, translating logical addresses to physical addresses, and calling
the driver to start the I/O.
LVM handles everything associated with request completion from the underlying
disk driver. This includes finding locating a mirror if one is not already
available, restarting requests previously blocked due to overlap, restarting
requests waiting for the Mirror Write Cache to be written, and other
functions.
LVM executes in interrupt context; thus, it is always interrupting user
processes. However, since it is not running in the context of a process, LVM
cannot access user process information. It also should complete as quickly as
possible and cannot go to sleep (for example, to wait to allocate memory).
The lv pseudo-device driver maintains the on-disk data structures that
describe the volume groups. Each volume group has a separate entry in the
kernel device switch table, with entry points for the logical volume device
driver and a pointer to the volume group data structure. Each volume group's
control device file, called group (logical volume number 0), provides the
means for manipulating the volume group's data structures. Each logical volume
in the volume group is accessible through a device node with its own unique
(non-zero) logical volume number.
To translate from a logical to physical operation, an lv_xlate function
converts the logical address consisting of the volume group, logical volume,
logical block, and mirror number, into a physical address consisting of
physical volume and physical block. A mirror number and logical block index
entry maps into the logical volume's extent map, which can then be used to
find the LVM disk.