Classes of Volumes

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

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

How Are Volumes 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. Like 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 "containing" 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 capacity.

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

Volume and Disk Space Expansion

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 shrunk. Not shrinking 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 applications can recognize it. Solaris Volume Manager does not provide this capability.

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

• Adding one or more slices to a RAID 0 volume

• Adding a slice or multiple slices to all submirrors of a RAID 1 volume

• Adding one or more slices to a RAID 5 volume

• Expanding a soft partition with additional space from the underlying component

The growfs Command

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. Likewise, when you expand a transactional volume, space is added to the master device. The growfs command is then run on the RAID 1 volume or the transactional volume, respectively. 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

Volume Name Requirements

There are a few rules that you must follow when assigning names for volumes:

• Volume names must begin with the letter "d" followed by a number (for example, d0).

• Solaris Volume Manager has 128 default volume names from 0-127. The following table shows some example volume names.

  Table 3-3 Example Volume Names

  /dev/md/dsk/d0	Block volume d0
  /dev/md/dsk/d1	Block volume d1
  /dev/md/rdsk/d126	Raw volume d126
  /dev/md/rdsk/d127	Raw volume d127

• Instead of specifying the full volume name, such as /dev/md/dsk/d1, you can often use an abbreviated volume name, such as d1, with any meta* command.

• Like 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.

• 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.

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:

• Use ranges for each particular type of volume. For example, assign numbers 0-20 for RAID 1 volumes, 21-40 for RAID 0 volumes, and so on.

• Use a naming relationship for mirrors. For example, name mirrors with a number that ends in zero (0), and submirrors that end in one (1) and two (2). For example, you might name mirrors as follows: mirror d10, submirrors d11 and d12; mirror d20, submirrors d21 and d22, and so on.

• Use a naming method that maps the slice number and disk number to volume numbers.

State Database and State Database Replicas

The state database is a database that stores information on disk 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. It is necessary that a Solaris Volume Manager configuration has an operating state database.

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

• On dedicated slices

• On slices that will later become part of volumes

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 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.