Managing Disks

File systems reside in a logical volume just as they do within disk sections or nonpartitioned disks. As of 10.10, the maximum size of HFS and JFS (VxFS) file systems increased from 4GB to 128GB. However, your root or boot logical volume is limited to either 2GB or 4GB, depending on your processor. (For more information on HFS and JFS, refer to “Determining What Type of File System to Use”.)

You can consider the space required by a file system as having three major components, as depicted in Figure 6-3 “File System Space Components”.

Figure 6-3 File System Space Components

To get a rough estimate of how big to make a logical volume which will contain your file system, do the following:

For example, suppose a group of users will require 60MB space for file system data; this estimate allows for expected growth. You then add 6MB for the “minfree” space and arrive at 66MB. Then you add another 3MB for file system overhead and arrive at a grand total estimate of 69MB required by the file system, and by consequence, for the logical volume that contains the file system. If you are creating the logical volume in a volume group that has an extent size of 4MB, 69 gets rounded up to 72 to make it divisible by 4MB. That is, LVM will create your logical volumes in multiples of the logical extent size.

Although estimates are not precise, they suffice for planning how big to make a file system. You want your file system to be large enough for some useful time before having to increase its size. On the other hand, a contiguous logical volume such as the root logical volume cannot be readily increased in size. Here, it is especially important to try to choose an estimate that will allow for all subsequent growth to such logical volumes.

Suppose as suggested above, your users have outgrown the space originally allocated for the file system. You can increase the size of a file system by first enlarging the logical volume it resides in and then using extendfs(1M). (More information can be found under “Extending the Size of a File System Within a Logical Volume ”).

You cannot decrease the size of a file system once it has been created. However, you can create a new smaller file system to take its place.

	NOTE: Because increasing the size of a file system is usually much easier than reducing its size, you might benefit by being conservative in estimating how large to create a file system. However, an exception to this would be the root file system since it is difficult to extend it.

Whenever possible, if you plan to have a file system span disks, have the logical volume span identical disk interface types. (See “Using Disk I/O Interfaces”.)

Normally, by default, LVM will create logical volumes on available disks, not necessarily with regard for best performance. It is possible to have a file system span two disks with different characteristics, in which case the file system performance could possibly be impaired.

As a system administrator, you can exercise control over which physical volumes will contain the physical extents of a logical volume. You can do this by using the following two steps:

For more detailed information on this procedure, see “Extending a Logical Volume to a Specific Disk ”.

When you enable a swap area within a logical volume, HP-UX determines how large the area is and it will use no more space than that. If your disk has enough remaining contiguous space, you can subsequently increase the size of your primary swap area by using the lvextend command (or SAM) to enlarge the logical volume and then reboot the system. This allows HP-UX to use the extra space that you have provided.

If you plan device swap areas in addition to primary swap, you will attain the best performance when the device swap areas are on different physical volumes (disks). This allows for the interleaving of I/O to the physical volumes when swapping occurs.

You set up this swapping configuration by creating multiple logical volumes for swap, each logical volume on a separate disk. You must use HP-UX commands to help you obtain this configuration; SAM does not allow you to create a logical volume on a specific disk. See “Extending a Logical Volume to a Specific Disk ”.

You can optimize raw I/O performance by planning your logical volumes specifically for raw data storage. To create a raw data logical volume (such as for a database), you will need to consider how large to create the logical volume and how such a logical volume is distributed over your disks.

Typically, you specify the size of a logical volume in megabytes. However, a logical volume’s size must be a multiple of the extent size used in the volume group. By default, the size of each logical extent is 4 MB.

So, for example, if a database partition requires 33MB and the default logical extent size is 4 MB, LVM will create a logical volume that is 36MB (or 9 logical extents).

The maximum supported size for a raw data device is 4 GB.

If you plan to use logical volumes heavily for raw data storage (such as for setting up database partitions), you should consider how the logical volumes are distributed over your disks.

By default, LVM will assign disk space for a logical volume from one disk, use up the space on this disk entirely, and then assign space from each successive disk in the same manner. LVM uses the disks in the order in which they were added to the volume group. This means that a logical volume’s data may not turn out to be evenly distributed over all the disks within your volume group.

As a result, when I/O access to the logical volumes occurs, one or more disks within the volume group may be heavily used, while the others may be lightly used, or not even used at all. This arrangement does not provide optimum I/O performance.

As a better alternative, you can set up your logical volume on specific disks in an interleaved manner, thus balancing the I/O access and optimizing performance. (See “Extending a Logical Volume to a Specific Disk ”.)

Because there are no HP-UX commands that will identify that the contents of a logical volume are being used for raw data, it is a good idea to name the logical volumes you create for raw data with easily recognizable names. In this way, you can recognize the contents of such a logical volume. See “Naming Logical Volumes” for more information.

LVM supports disks that use SCSI, HP-FL, and, to a limited extent, HP-IB I/O interface types, as shown in Table 6-1 “Disk Interface Types and LVM Support ”.

Although the table shows that mixed HP-FL and SCSI disks can belong to the same volume group, for best performance, you should keep them in separate groups, each containing identical model disks; that is, each should have the same characteristics such as size and rotational speed. HP-IB disks cannot be mixed with the other types.

	NOTE: LVM can be used on all Series 700 and 800 supported disks. HP-IB disks are not supported on Series 700 systems.

If as a result of a defect on the disk, LVM is unable to store data, a mechanism is provided to store it at the end of the disk. If your disk supports automatic bad block relocation (usually known as “hardware sparing”), then LVM’s bad block relocation mechanism is unnecessary.

Bad block relocation is in effect by default when a logical volume is created. You can use the -r n option of lvcreate(1M) to disable the bad block relocation feature.

	NOTE: Bad block relocation is not supported for root, swap, or dump logical volumes, or on physical volumes larger than 256GB. As of HP-UX 11i version 2, LVM no longer performs bad block relocation in software, but defers to the hardware bad block relocation implemented within modern disks and disk arrays. LVM recognizes and honors software relocation entries created by previous releases, but will not create new ones. Enabling or disabling bad block relocation via lvchange has no effect. The -r option of lvcreate cannot be used with HP-IB devices.

Your hardware may provide the capability for dual cabling (dual controllers) to the same physical volume. This will be true if your organization has purchased an HP High Availability Disk Array or the MC/ServiceGuard product. If so, LVM can be configured with multiple paths to the same physical volume. If the primary link fails, an automatic switch to an alternate link will occur. Using alternate links will increase availability. See “Setting Up Alternate Links to a Physical Volume ”.

Physical volumes are identified by their device file names, for example:

Note that each disk has a block device file and a character or raw device file, the latter identified by the r. Which name you use depends on what task you are doing with the disk. In the notation above, the first two names represent block device files while the second two are raw device files.

On HP Integrity Servers, make sure to use the device file with the s2 suffix, as that represents the HP-UX partition on the disk. On HP 9000 (PA-RISC) systems, use the device file without a partition number.

Use a physical volume’s raw device file for these two tasks only:

For all other tasks, use the block device file. For example, when you add a physical volume to a volume group, you use the disk’s block device file for the disk, such as /dev/dsk/c5t3d0.

For more information on device file names, see Configuring HP-UX for Peripherals.

All disk device files are created automatically when you boot the system, after you have physically added the disk. Refer to insf(1M) for more information.

When choosing a name for a volume group, the name must be identical to the name of a directory you have created under /dev. (See Steps 3 and 4 under “Example: Creating a Logical Volume Using HP-UX Commands”.) The name can have up to 255 characters.

Each volume group must have a unique name. For example, typical volume group names could be vg01, vgroot, or vg_sales. Although the name does not have to start with vg, this is highly encouraged. Often, these names take the form: /dev/vgnn. When assigned by default, the number nn starts at 00 and proceeds 01, 02, and so on, in the order that volume groups are created. By default, your root volume group will be vg00 although this name is not required; see “Creating Root Volume Group and Root and Boot Logical Volumes ” later for more information on the root volume group.

Logical volumes are identified by their device file names which can either be assigned by you or assigned by default when you create a logical volume using lvcreate(1M).

When assigned by you, you can choose whatever name you wish up to 255 characters.

When assigned by default, these names take the form: /dev/vgnn/lvolN (the block device file form) and /dev/vgnn/rlvolN (the character device file form). The number N starts at 1 and proceeds 2, 3, and so on, in the order that logical volumes are created within each volume group.

When LVM creates a logical volume, it creates both block and character device files. LVM then places the device files for a logical volume in the appropriate volume group directory.

For example, the default block name for the first logical volume created in volume group vg01 would have the full path name:

/dev/vg01/lvol1

If you create a logical volume to contain raw data for a sales database, you might want to name it using a nondefault name:

/dev/vg01/sales_db_lv

After the logical volume in the above example has been created, it will have two device files:

/dev/vg01/sales_db_lv    block device file
/dev/vg01/rsales_db_lv   character, or raw, device file

Physical volume groups are useful for mirroring and are discussed under “Managing Mirrored File Systems”. The only naming restriction in this case is that within a volume group, each physical volume group must have its own unique name. For example, the volume group /dev/vg02 might have two physical volume groups called /dev/vg02/pvg1 and /dev/vg02/pvg2.

To create a logical volume, do the following procedure:

Suppose you want to create a 300 MB logical volume and put 100 MB on your first disk, another 100 MB on your second disk, and 100 MB on your third disk. To do so, follow these steps:

Note that when you use the -l option (lowercase L) of lvextend, you specify space in logical extents.

Now suppose you have two disks in a volume group, both identical models. You currently have a 275 MB logical volume that resides on only one of the disks. You want to extend the logical volume size to 400 MB, making sure the 125 MB increase is allocated to the other disk.

Again you extend the logical volume to a specific disk.

Here, when you use the -L option (uppercase), you are specifying space in megabytes, not logical extents.

See lvextend(1M) for complete information on command options.

	NOTE: VERITAS Volume Manager (VXVM).  The VERITAS Volume Manager included in the operating environments as of the September 2002 release of HP-UX 11i version (B.11.11) enables rootability. With VxVM rootability, you can choose to configure your root volume during installation with Ignite-UX, or you can use the conversion tools installed with VxVM to configure your root volume at a later time. For more information, read the VERITAS Volume Manager 3.5 Installation Guide for more details. Before you consider setting your root volume to VxVM, be sure to read the VERITAS Volume Manager 3.5 Release Notes and the VERITAS Volume Manager 3.5 Migration Guide on http://docs.hp.com for more detailed information about VxVM and rootability. Please note that there can be newer versions of these documents available on the documentation website.

With non-LVM disks, a single root disk contained all the attributes needed for boot up as well as your system files, primary swap, and dump. Using LVM, a single root disk is replaced by a pool of disks, a root volume group, which contains all of the same elements but allowing a root logical volume, a boot logical volume, a swap logical volume, and one or more dump logical volumes. Each of these types of logical volumes must be contiguous, that is, contained on a single disk. (Additionally, there can be other noncontiguous logical volumes which might be used for user data.) See “Managing Swap and Dump” for more information on the swap and dump logical volumes.

The root logical volume contains the operating system software. You have the option of using a separate boot logical volume instead of combining root and boot operations within a single logical volume. When you configure both a root and boot logical volume, you store information that enables the system to locate the kernel in two locations rather than only one which is the case with using just the root logical volume. As a result, you will still be able to boot the system even if the LABEL file, normally essential to a system boot, becomes corrupt.

Whether you use a single “combined” root-boot logical volume, or separate root and boot logical volumes, the logical volume used to boot the system must be the first logical volume on its physical volume. If the root logical volume is not the first logical volume on its physical volume, then you must also configure a boot logical volume. Both a root logical volume and a boot logical volume must be contiguous with bad block relocation disabled.

If you newly install your 11.00 system and choose the LVM configuration, a root volume group is automatically configured, as are separate root and boot logical volumes. If you currently have a combined root and boot logical volume and you wish to reconfigure to separate root and boot logical volumes, after creating the boot logical volume, you will need to use the lvlnboot(1M) command with the -b option to define the boot logical volume to the system, taking effect the next time the system is booted. For example:

If you decide you want to create a root volume group “from scratch” that will contain an alternate boot disk, you can follow the steps below. You can also use these steps, with some minor changes, if you need to modify an existing root logical volume, including increasing its size, or perhaps changing your configuration to a combined root-boot logical volume. When modifying an existing root logical volume, be sure to back up your current root logical volume before proceeding and then copy it back to the new file system upon completion.

Now you are ready to create a logical volume that you intend to use for root. You usually want to place this logical volume on a specific physical volume. If you are configuring a combined root-boot logical volume, the root logical volume must be the first logical volume found on the bootable LVM disk. In this case, this means that the root logical volume must begin at physical extent 0000. This is important in the event it is necessary to boot the system in maintenance mode. A disk that will contain a root logical volume should not have non-root data in the region following the boot area.

	NOTE: You can use pvmove(1M) to move the data from an existing logical volume to another disk, if it’s necessary to make room for the root logical volume.

Continue by following these additional steps:

Once the root logical volume is created, you will need to create a file system (see “Creating a File System”).

It is important that volume group configuration information be saved whenever you make any change to the configuration such as:

This is because unlike with fixed disk sections or nonpartitioned disks that begin and end at known locations on a given disk, each volume group configuration is unique, changes at times, and may use space on several disks.

As a result of your volume group configuration having been saved, you will be able to restore a corrupted or lost LVM configuration in the event of a disk failure or if your LVM configuration information is destroyed (for example, through the accidental or incorrect use of commands such as newfs or dd).

The vgcfgbackup command is used to create or update a backup file containing the volume group’s configuration. (vgcfgbackup does not back up the data within your logical volumes; use the backup procedures described in “Backing Up Data”). To simplify the backup process, vgcfgbackup is invoked automatically by default whenever you make a configuration change as a result of using any of the following commands:

You can display LVM configuration information previously backed up with vgcfgbackup or restore it using vgcfgrestore.

By default, vgcfgbackup saves the configuration of a volume group to the file /etc/lvmconf/volume_group_name.conf.

If you choose, you can run vgcfgbackup at the command line, saving the backup file in any directory you indicate. If you do, first run vgdisplay with the -v option to make sure that the all logical volumes in the volume group are shown as available/syncd; if so, then run:

If you use a nondefault volume group configuration file, be sure to take note of and retain its location. Refer to vgcfgbackup(1M) for information on command options.

Before running vgcfgrestore, you need to deactivate the volume group with vgchange(1M).

For example, to restore volume group configuration data for /dev/dsk/c4t0d0, a disk in the volume group /dev/vgsales, enter:

This restores the LVM configuration to the disk from the default backup location in /etc/lvmconf/vgsales.conf.

To activate the volume group, run vgchange again:

Refer to vgcfgrestore(1M) for information on command options.

There are occasions when you might need to:

	CAUTION: Moving a disk which is part of your root volume group is not recommended. See Configuring HP-UX for Peripherals for more information.

The file /etc/lvmtab contains information about the mapping of LVM disks on a system to volume groups, that is, volume group names and lists of the physical volumes included in volume groups. When you do either of the above tasks, the LVM configuration file, /etc/lvmtab, must be changed to reflect the new hardware locations and device files for the disks. However, you cannot edit this file directly, since it is not a text file. Instead, you must use vgexport and vgimport to reconfigure the volume groups. This results in the configuration changes being recorded in the /etc/lvmtab file.

You can use pvmove to move data contained in logical volumes from one disk to another disk or to move data between disks within a volume group.

For example, you might want to move only the data from a specific logical volume from one disk to another to use the vacated space on the first disk for some other purpose. To move the data in logical volume /dev/vg01/markets from the disk /dev/dsk/c0t0d0 to the disk /dev/dsk/c1t0d0, enter

pvmove -n /dev/vg01/markets /dev/dsk/c0t0d0 \
  /dev/dsk/c1t0d0

On the other hand, you might prefer to move all the data contained on one disk, regardless of which logical volume it is associated with, to another disk within the same volume group. You might want to do this, for example, so you can remove a disk from a volume group. You can use pvmove to move the data to other specific disks you choose or let LVM move the data to appropriate available space within the volume group.

To move all data off disk /dev/dsk/c0t0d0 and relocate it at the destination disk /dev/dsk/c1t0d0, enter:

pvmove /dev/dsk/c0t0d0 /dev/dsk/c1t0d0

To move all data off disk /dev/dsk/c0t0d0 and let LVM transfer the data to available space within the volume group, enter:

pvmove /dev/dsk/c0t0d0

In each of the above instances, if space doesn’t exist on the destination disk, the pvmove command will not succeed.

You might want to reduce the size of a logical volume for several reasons:

You reduce the size of a logical volume using the lvreduce command.

If you are using the disk space for a new purpose and do not need the data contained in the logical volume, no backup is necessary. If, however, you want to retain the data that will go into the smaller logical volume, you must back it up first and then restore it once the smaller logical volume has been created.

As an alternate to using lvreduce, you can also use the lvremove command instead to remove the logical volume followed by lvcreate to create a new one.

	CAUTION: Reduce the size of a logical volume ONLY if you no longer need its current contents, or if you have safely backed up the contents to tape or to another logical volume. After reducing the size of a logical volume to a size smaller than a file system contained within the logical volume, you must re-create the file system as described in “Creating a File System”, and restore the files. Thus, it is critical to be aware of the size of the contents of a logical volume when you plan to reduce the size of the logical volume. See “Problems After Reducing the Size of a Logical Volume” for more information. It is not a simple task to reduce the size of a given file system once it has been created. See “Reducing a Logical Volume” and “Replacing an Existing File System with a Smaller One ” for more information.

Alternate links to a physical volume were described earlier under “Increasing Availability with Alternate Links”. To use an alternate link, you can create a volume group with vgcreate specifying both the primary link and the alternate link device file names. Both must represent paths to the same physical volume. (Do not run pvcreate on the alternate link; it must already be the same physical volume as the primary link.) When you indicate two device file names both referring to the same disk using vgcreate, LVM configures the first one as the primary link and the second one as the alternate link.

For example, if a disk has two cables and you want to make one the primary link and the other an alternate link, enter:

vgcreate /dev/vg01 /dev/dsk/c3t0d0 /dev/dsk/c5t0d0

To add an alternate link to a physical volume that is already part of a volume group, use vgextend to indicate the new link to the physical volume. For example, if /dev/dsk/c2t0d0 is already part of your volume group but you wish to add another connection to the physical volume, enter:

vgextend /dev/vg02 /dev/dsk/c4t0d0

If the primary link fails, LVM will automatically switch from the primary controller to the alternate controller. However, you can also tell LVM to switch to a different controller at any time by entering, for example

pvchange -s /dev/dsk/c2t1d0

After the primary link has recovered, LVM will automatically switch back from the alternate controller to the original controller unless you previously instructed it not to by using pvchange as illustrated below:

pvchange -S n /dev/dsk/c2t2d0

The current links to a physical volume can be viewed using vgdisplay with the -v option.

You can temporarily disable one or all of the physical paths, or links, to a physical volume using the pvchange command. Disabling a link, also known as detaching the link, causes LVM to close that path to the device and stop using it; this can be useful if you want to guarantee that a link is idle, such as when you are running diagnostics on an I/O card, replacing an I/O card, or replacing the disk containing the physical volume.

Detaching a link to a physical volume is intended to be a temporary operation, not a permanent one. If you want to permanently remove a link or physical volume from the volume group, use vgreduce instead.

To detach a link to a physical volume, use the -a option to pvchange. For example, to disable the link through the device /dev/dsk/c5t0d0, enter:

pvchange -a n /dev/dsk/c5t0d0

To detach all links to a physical volume, use N as the argument to the -a option:

pvchange -a N /dev/dsk/c5t0d0

Detaching one or more links to a physical volume will not necessarily cause LVM to stop using that physical volume entirely. If the detached link is the primary path to the device, LVM will begin using any available alternate link to it. LVM will only stop using the physical volume when all the links to it are detached.

If all the links to a device are detached, the associated physical volume will be unavailable to the volume group. The links remain associated with the volume group but no I/O requests will be queued to it by LVM until it is reattached. This means that the data on that physical volume will be temporarily unavailable; consequently, you as the adminstrator must make sure that any availability requirements for that data can be satisfied, by mirroring if necessary, before you make the device unavailable by detaching it.

Detaching a link does not disable sparing. That is, if all links to a physical volume are detached, and a suitable spare physical volume is available in the volume group, LVM will use it to reconstruct the detached disk. For more information on sparing, see “Maintaining High Availability in the Event of Disk Failure”.

You can view the status of all links to a physical volume using vgdisplay with the -v option.

Restoring a detached link to a physical volume, or reattaching it, makes that link available to the volume group. LVM may begin using that link as necessary to access the disk.

To reattach a specific path to a physical volume, use the pvchange command with the -a option. For example, enter:

pvchange -a y /dev/dsk/c5t0d0

Because detaching a link to a physical volume is meant to be temporary, all detached links in a volume group are reattached when the volume group is activated, either at boot time or with an explicit vgchange command, such as:

vgchange -a y /dev/vg02

When you use disk striping, you create a logical volume that spans multiple disks, allowing successive blocks of data to go to logical extents on different disks. For example, a three-way striped logical volume has data allocated on three disks, with each disk storing every third block of data. The size of each of these blocks is referred to as the stripe size of the logical volume.

Disk striping can increase the performance of applications that read and write large, sequentially accessed files. Data access is performed over the multiple disks simultaneously, resulting in a decreased amount of required time as compared to the same operation on a single disk. If all of the striped disks have their own controllers, each can process data simultaneously.

You can use familiar, standard commands to manage your striped disks. For example, lvcreate(1M), diskinfo(1M), newfs(1M), fsck(1M), and mount(1M) will all work with striped disks.

The following guidelines, most of which apply to LVM disk usage in general, apply especially to striped logical volumes for performance reasons:

Follow these steps to create a a striped logical volume:

Determining Optimum Stripe Size

The logical volume’s stripe size identifies the size of each of the blocks of data that make up the stripe. You can set the stripe size to four, eight, 16, 32, or 64 kilobytes (KB) (the default is eight KB).

	NOTE: The stripe size of a logical volume is not related to the physical sector size of a disk, which is typically 512 bytes.

How you intend to use the striped logical volume determines what stripe size you assign to it.

For best results:

• If you plan to use the striped logical volume for an HFS file system:

  Select the stripe size that most closely reflects the block size of the file system. The newfs command lets you specify a block size when you build the file system and provides a default block size of eight KB for HFS.

• If you plan to use the striped logical volume for a JFS (VxFS) file system:

  Use the largest available size, 64KB. For I/O purposes, JFS combines blocks into extents, which are variable in size and may be very large. The configured block size, 1KB by default (which in any case governs only direct blocks), is not significant in this context. See “Frequently Asked Questions about the Journaled File System” for more information.

• If you plan to use the striped logical volume as swap space:

  Set the stripe size to 16KB for best performance. See “Setting Up Logical Volumes for Swap” and “Configuring Primary and Secondary Swap ” for information on configuring swap.

• If you plan to use the striped logical volume as a raw data partition (for example, for a database application that uses the device directly):

  The stripe size should be the same as the primary I/O size for the application.

You may need to experiment to determine the optimum stripe size for your particular situation. To change the stripe size, you will need to re-create the logical volume.

If you cannot boot from a logical volume, a number of things might be responsible for this situation. In addition to the same kinds of problems associated with boots from non-LVM disks, any of the following could cause an LVM-based system not to boot:

The first and last of these items will now be discussed in further detail.

When a Volume Group Will Not Activate

Normally, volume groups are automatically activated during system startup. Unless you intentionally deactivate a volume group using vgchange, you will probably not need to activate a volume group. However, LVM does require that a quorum of disks in a volume group be available. During bootup, LVM needs a quorum of more than half of the disks that are included in the root volume group for activation of that volume group; this means the majority of these disks must be online and in service. Thus, if there are two disks in the root volume group, the more than half requirement means that both will need to be available. To successfully boot the system, LVM will require a quorum of one more than half of the disks in the root volume group.

Another possible problem pertaining to activation of a volume group is a missing or corrupted /etc/lvmtab file. You can use the vgscan(1M) command to re-create the /etc/lvmtab file.

During run time, once a volume group is already active, if a disk fails or is taken off line, quorum may become lost. This will occur if less than half of the physical volumes defined for the volume group now remain available. For example, if there are two disks in the volume group, the loss of one would not cause a loss of quorum, as is the case when booting; rather, both disks would need to become unavailable. If this happened, your volume group will still remain active; however, a message will be printed to the console indicating that the volume group has lost quorum. Until the quorum is restored (at least one of the LVM disks in the volume group in the above example is once again available), LVM will not allow you to complete most commands that affect the volume group configuration. Further, some of the I/O accesses to the logical volumes for that volume group may hang because the underlying disks are not accessible. Also, until quorum is restored, the Mirror Write Cache (MWC) will not be updated because LVM cannot guarantee the consistency (integrity) of the LVM information.

Even when allowed by LVM, it is recommended that you do not make changes to the LVM configuration for active volume groups that do not have a quorum of disks present.

There are ways to override quorum requirements at volume group activation time, or at boot time. These will be discussed in the following two sections. However, the recommended way to correct this problem is to return the unavailable disks to service.

Quorum Problems with a Non-Root Volume Group

If you attempt to activate a nonroot volume group when not enough disks are present to establish a quorum, you will see error messages similar to the following:

vgchange -a y /dev/vg01 vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c1t0d2": The path of the physical volume refers to a device that does not exist, or is not configured into the kernel. vgchange: Couldn't activate volume group "/dev/vg01": Either no physical volumes are attached or no valid VGDAs were found on the physical volumes.

If a nonroot volume group does not get activated because of a failure to meet quorum, try the following:

1. Check the power and data connections of all the disks that are part of the volume group that you cannot activate. Return all disks (or, at least enough to make a quorum) to service. Then, use the vgchange command to try to activate the volume group again.

2. If there is no other way to make a quorum available, the -q option of the vgchange command will override the quorum requirement.

   vgchange -a y -q n /dev/vg01

   As a result, the volume group will activate without a quorum being present. You might get messages about not being able to access certain logical volumes. This is because part or all of a logical volume might be located on one of the disks that is not present.

   Whenever you override a quorum requirement, you run the risk of using data that are not current. Be sure to check the data on the logical volumes in the activated volume group as well as the size and locations of the logical volumes to ensure that they are up-to-date.

   You should attempt to return the disabled disks to the volume group as soon as possible. When you return a disk to service that was not online when you originally activated the volume group, you should once again use vgchange.

   vgchange -a y /dev/vg01

Quorum Problems with Your Root Volume Group

Your root volume group might also have a quorum problem. If there are not enough disks present in the root volume group to constitute a quorum, a message indicating that not enough physical volumes are present will be displayed during the boot sequence. This might occur if you have physically removed a disk from your system because you no longer intended to use it with the system, but did not remove the physical volume from the volume group using vgreduce. Although you should never remove an LVM disk from a system without first removing it from its volume group, you can probably recover from this situation by booting your system with the quorum override option, hpux -lq.

When a file system is first created within a logical volume, it is made as large as the logical volume will permit.

If you extend the logical volume without extending its file system, you can subsequently safely reduce the logical volume’s size as long as it remains as big as its file system. (Use bdf(1M) to determine the size of your file system.) Once you use the extendfs command to expand the file system, you can no longer safely reduce the size of the associated logical volume.

If you reduce the size of a logical volume containing a file system to a size smaller than that of a file system within it using the lvreduce command, you will corrupt the file system. If you subsequently attempt to mount the corrupt file system, you may crash your system. If this occurs:

When a device driver returns an error to LVM on an I/O request, LVM classifies the error as either non-recoverable or recoverable. How those errors are handled determines your course of action.

Non-Recoverable Errors

Non-recoverable errors are considered fatal; there’s no expectation that retrying the operation could work. LVM considers two specific situations as non-recoverable:

If you have a current copy of the data on a separate, functioning mirror, then LVM directs reads and writes to a mirror copy. As far as the application accessing the logical volume is concerned, the I/O operation completes successfully.

However, if you have no other copies of the data — that is, the only copy of the data is on that physical volume — then LVM returns an error to whatever subsystem is accessing the logical volume. This means that any application directly accessing a logical volume should be prepared for I/O requests to fail. File systems such as VxFS and most database applications are designed to recover from error situations; for example, if VxFS encounters an I/O error, it may disable access to a file system or a subset of the files in it.

Dealing with Non-Recoverable Errors

How you deal with a non-recoverable error depends on what kind of problem LVM encountered. For a media error, you’ll have to replace the disk; for a procedure to do that, see “Replacing a Mirrored Disk”. For a device that wasn’t present at activation time, either locate the disk and restore it to service, or replace it using the same procedure, then activate the volume group again.

Recoverable Errors

When LVM encounters a recoverable, or “correctable” error, it will internally retry the failed operation, under the assumption that the error will correct itself, or that you as system administrator can take steps to correct it. Examples of recoverable errors are device power failure, a disk that goes missing after the volume group is activated, or a loose disk cable — which can manifest itself as a missing disk. In these cases, LVM will log an error message to the console, but it will not return an error to the application accessing the logical volume.

If you have a current copy of the data on a separate, functioning mirror, then LVM directs the I/O to a mirror copy, much as it would for a non-recoverable error. Applications accessing the logical volume will not see any error. (To preserve data synchronization between its mirrors, LVM will retry recoverable write requests to a problematic disk, even if there’s a current copy elsewhere; however, this is managed by a daemon internal to LVM, and has no impact on user access to the logical volume.)

If, however, the device in question holds the only copy of the data, LVM will retry the I/O request until it succeeds — that is, until the device responds or the system is rebooted. Any application performing I/O to the logical volume may block, waiting for the device to recover. In this case, your application or file system may appear to be “hung,” and may be unresponsive.

Dealing with Recoverable Errors

By default, LVM will retry I/O requests with recoverable errors until they succeed or the system is rebooted. Therefore, if an application or file system hangs, your troubleshooting should include checking the console log for problems with your disk drives, and taking action to restore the failing devices to service.

If for some reason retrying the I/O request will never succeed — such as if the disk was physically removed and taken away — your application or file system may block indefinitely. If your application is not responding, you may have to reboot your system.

As an alternative to rebooting, you can control how long LVM will retry a recoverable error before treating it as non-recoverable, by setting a timeout on the logical volume.

Logical Volume Timeouts

The -t option to the lvchange command sets the timeout value in seconds for a logical volume. For example, to set the timeout for /dev/vg01/lvol1 to one minute, enter:

lvchange -t 60 /dev/vg01/lvol1

This command sets the maximum length of time that LVM will retry an I/O request. If the device fails to respond within that time, LVM will return an I/O error to the caller. The timeout value is normally zero, which is interpreted as an infinite timeout; thus, by default no I/O request will return to the caller until it completes successfully.

If you want to enable a timeout on a logical volume, you should set it to an integral multiple of any timeout assigned to the underlying physical volume(s). Otherwise, the actual duration of the I/O request may exceed the logical volume’s timeout. See pvchange(1M) for details on how to change the I/O timeout value on a physical volume.

You can view the timeout value for a logical volume using the lvdisplay command.

	CAUTION: Setting a timeout on a logical volume increases the likelihood of transient errors being treated as non-recoverable errors, so any application that reads or writes to the logical volume may experience I/O errors. If your application is not prepared to handle such errors, keep an infinite logical volume timeout.

You might occasionally see long periods of apparent inactivity by programs that are accessing disks. Such programs may be “hung”, waiting for access to a currently inaccessible disk. Messages indicating the disk is offline will also appear on your system console.

If the logical volume is mirrored on to another disk, LVM marks the disk as offline and continues the operation on any remaining mirror disk. If the logical volume is not mirrored, or if the mirror copies of the logical volume are also not available, the program will remain hung until a disk becomes accessible. Therefore, if your program hangs, you should check for problems with your disk drives and, if necessary, restore them to service as soon as possible.