JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Solaris Volume Manager Administration Guide
search filter icon
search icon

Document Information


1.  Getting Started With Solaris Volume Manager

2.  Storage Management Concepts

3.  Solaris Volume Manager Overview

What's New in Solaris Volume Manager

Introduction to Solaris Volume Manager

How Solaris Volume Manager Manages Storage

How to Administer Solaris Volume Manager

How to Access the Solaris Volume Manager Graphical User Interface (GUI)

Solaris Volume Manager Requirements

Overview of Solaris Volume Manager Components

Overview of Volumes

Classes of Volumes

How Volumes Are Used

Example--Volume That Consists of Two Slices

Volume and Disk Space Expansion Using the growfs Command

Volume Names

Volume Name Guidelines

State Database and State Database Replicas

Hot Spare Pools

Disk Sets

Solaris Volume Manager Configuration Guidelines

General Guidelines

File System Guidelines

Overview of Creating Solaris Volume Manager Components

Prerequisites for Creating Solaris Volume Manager Components

Overview of Multi-Terabyte Support in Solaris Volume Manager

Large Volume Support Limitations

Using Large Volumes

Upgrading to Solaris Volume Manager

4.  Solaris Volume Manager for Sun Cluster (Overview)

5.  Configuring and Using Solaris Volume Manager (Scenario)

6.  State Database (Overview)

7.  State Database (Tasks)

8.  RAID-0 (Stripe and Concatenation) Volumes (Overview)

9.  RAID-0 (Stripe and Concatenation) Volumes (Tasks)

10.  RAID-1 (Mirror) Volumes (Overview)

11.  RAID-1 (Mirror) Volumes (Tasks)

12.  Soft Partitions (Overview)

13.  Soft Partitions (Tasks)

14.  RAID-5 Volumes (Overview)

15.  RAID-5 Volumes (Tasks)

16.  Hot Spare Pools (Overview)

17.  Hot Spare Pools (Tasks)

18.  Disk Sets (Overview)

19.  Disk Sets (Tasks)

20.  Maintaining Solaris Volume Manager (Tasks)

21.  Best Practices for Solaris Volume Manager

22.  Top-Down Volume Creation (Overview)

23.  Top-Down Volume Creation (Tasks)

24.  Monitoring and Error Reporting (Tasks)

25.  Troubleshooting Solaris Volume Manager (Tasks)

A.  Important Solaris Volume Manager Files

B.  Solaris Volume Manager Quick Reference

C.  Solaris Volume Manager CIM/WBEM API


Overview of Solaris Volume Manager Components

The five basic types of components that you create with Solaris Volume Manager are volumes, soft partitions, disk sets, state database replicas, and hot spare pools. The following table gives an overview of these Solaris Volume Manager features.

Table 3-1 Summary of Solaris Volume Manager Features

Solaris Volume Manager Feature
For More Information
  • RAID-0 volume (stripe, concatenation, concatenated stripe)

  • RAID-1 (mirror) volume

  • RAID-5 volume

A group of physical slices that appear to the system as a single, logical device
To increase storage capacity, performance, or data availability.
Soft partition
A subdivision of physical slices or logical volumes to provide smaller, more manageable storage units
To improve manageability of large storage volumes.
State database (state database replicas)
A database that contains configuration and status information for all volumes, hot spares, and disk sets. Solaris Volume Manager cannot operate until you have created the state database replicas.
To store information about the state of your Solaris Volume Manager configuration
Hot spare pool
A collection of slices (hot spares) reserved. These slices are automatically substituted when either a submirror or RAID-5 volume component fails.
To increase data availability for RAID-1 and RAID-5 volumes.
Disk set
A set of shared disk drives in a separate namespace that contains volumes and hot spares and that can be shared non-concurrently by multiple hosts
To provide data redundancy and data availability and to provide a separate namespace for easier administration.

Overview of Volumes

A volume is a group of physical slices that appears to the system as a single, logical device. Volumes are actually pseudo, or virtual, devices in standard UNIX terms.

Note - Historically, the Solstice DiskSuite product referred to these logical devices as metadevices. However, for simplicity and standardization, this book refers to these devices as volumes.

Classes of Volumes

You create a volume as a RAID-0 (concatenation or stripe) volume, a RAID-1 (mirror) volume, a RAID-5 volume, or a soft partition.

You can use either the Enhanced Storage tool within the Solaris Management Console or the command-line utilities to create and administer volumes.

The following table summarizes the classes of volumes.

Table 3-2 Classes of Volumes

RAID-0 (stripe or concatenation)
Can be used directly, or as the basic building block for mirrors. RAID-0 volumes do not directly provide data redundancy.
RAID-1 (mirror)
Replicates data by maintaining multiple copies. A RAID-1 volume is composed of one or more RAID-0 volumes that are called submirrors.
Replicates data by using parity information. In the case of disk failure, the missing data can be regenerated by using available data and the parity information. A RAID-5 volume is generally composed of slices. One slice's worth of space is allocated to parity information, but the parity is distributed across all slices in the RAID-5 volume.
Soft partition
Divides a slice or logical volume into one or more smaller, extensible volumes.
How Volumes Are Used

You use volumes to increase storage capacity, performance, and data availability. In some instances, volumes can also increase I/O performance. Functionally, volumes behave the same way as slices. Because volumes look like slices, the volumes are transparent to end users, applications, and file systems. As with physical devices, volumes are accessed through block or raw device names. The volume name changes, depending on whether the block or raw device is used. See Volume Names for details about volume names.

You can use most file system commands, including mkfs, mount, umount, ufsdump, ufsrestore, and others, on volumes. You cannot use the format command, however. You can read, write, and copy files to and from a volume, as long as the volume contains a mounted file system.

Example—Volume That Consists of Two Slices

Figure 3-2 shows a volume that contains two slices, one slice from Disk A and one slice from Disk B. An application or UFS treats the volume as if it were one physical disk. Adding more slices to the volume increases its storage capacity.

Figure 3-2 Relationship Among a Volume, Physical Disks, and Slices

Diagram shows two disks, and how slices on those disks are presented by Solaris Volume Manager as a single logical volume.
Volume and Disk Space Expansion Using the growfs Command

Solaris Volume Manager enables you to expand a volume by adding additional slices. You can use either the Enhanced Storage tool within the Solaris Management Console or the command-line interface to add a slice to an existing volume.

You can expand a mounted or unmounted UFS file system that is contained within a volume without having to halt or back up your system. Nevertheless, backing up your data is always a good idea. After you expand the volume, use the growfs command to grow the file system.

Note - After a file system has been expanded, the file system cannot be reduced in size. The inability to reduce the size of a file system is a UFS limitation. Similarly, after a Solaris Volume Manager partition has been increased in size, it cannot be reduced.

Applications and databases that use the raw volume must have their own method to “grow” the added space so that applications can recognize it. Solaris Volume Manager does not provide this capability.

You can expand the disk space in volumes in the following ways:

The growfs command expands a UFS file system without loss of service or data. However, write access to the volume is suspended while the growfs command is running. You can expand the file system to the size of the slice or the volume that contains the file system.

The file system can be expanded to use only part of the additional disk space by using the -s size option to the growfs command.

Note - When you expand a mirror, space is added to the mirror's underlying submirrors. The growfs command is then run on the RAID-1 volume. The general rule is that space is added to the underlying devices, and the growfs command is run on the top-level device.

Volume Names

As with physical slices, volumes have logical names that appear in the file system. Logical volume names have entries in the /dev/md/dsk directory for block devices and the /dev/md/rdsk directory for raw devices. Instead of specifying the full volume name, such as /dev/md/dsk/volume-name, you can often use an abbreviated volume name, such as d1, with any meta* command. You can generally rename a volume, as long as the volume is not currently being used and the new name is not being used by another volume. For more information, see Exchanging Volume Names.

Originally, volume names had to begin with the letter “d” followed by a number (for example, d0). This format is still acceptable. The following are examples of volume names that use the “d*” naming construct:


Block volume d0


Block volume d1


Raw volume d126


Raw volume d127

Volume Name Guidelines

The use of a standard for your volume names can simplify administration and enable you at a glance to identify the volume type. Here are a few suggestions:

State Database and State Database Replicas

The state database is a database that stores information about the state of your Solaris Volume Manager configuration. The state database records and tracks changes made to your configuration. Solaris Volume Manager automatically updates the state database when a configuration or state change occurs. Creating a new volume is an example of a configuration change. A submirror failure is an example of a state change.

The state database is actually a collection of multiple, replicated database copies. Each copy, referred to as a state database replica, ensures that the data in the database is always valid. Multiple copies of the state database protect against data loss from single points-of-failure. The state database tracks the location and status of all known state database replicas.

Solaris Volume Manager cannot operate until you have created the state database and its state database replicas. A Solaris Volume Manager configuration must have an operating state database.

When you set up your configuration, you can locate the state database replicas on either of the following:

Solaris Volume Manager recognizes when a slice contains a state database replica, and automatically skips over the replica if the slice is used in a volume. The part of a slice reserved for the state database replica should not be used for any other purpose.

You can keep more than one copy of a state database on one slice. However, you might make the system more vulnerable to a single point-of-failure by doing so.

The Solaris operating system continues to function correctly if all state database replicas are deleted. However, the system loses all Solaris Volume Manager configuration data if a reboot occurs with no existing state database replicas on disk.

Hot Spare Pools

A hot spare pool is a collection of slices (hot spares) reserved by Solaris Volume Manager to be automatically substituted for failed components. These hot spares can be used in either a submirror or RAID-5 volume. Hot spares provide increased data availability for RAID-1 and RAID-5 volumes. You can create a hot spare pool with either the Enhanced Storage tool within the Solaris Management Console or the command-line interface.

When component errors occur, Solaris Volume Manager checks for the first available hot spare whose size is equal to or greater than the size of the failed component. If found, Solaris Volume Manager automatically replaces the component and resynchronizes the data. If a slice of adequate size is not found in the list of hot spares, the submirror or RAID-5 volume is considered to have failed. For more information, see Chapter 16, Hot Spare Pools (Overview).

Disk Sets

A disk set is a set of physical storage volumes that contain logical volumes and hot spares. Volumes and hot spare pools must be built on drives from within that disk set. Once you have created a volume within the disk set, you can use the volume just as you would a physical slice.

A disk set provides data availability in a clustered environment. If one host fails, another host can take over the failed host's disk set. (This type of configuration is known as a failover configuration.) Additionally, disk sets can be used to help manage the Solaris Volume Manager namespace, and to provide ready access to network-attached storage devices.

For more information, see Chapter 18, Disk Sets (Overview).