voldisk - Define and manage Logical Storage Manager (LSM) disks
/sbin/voldisk init accessname [attribute...]
/sbin/voldisk define accessname [attribute...]
/sbin/voldisk moddb accessname [attribute...]
/sbin/voldisk offline accessname...
/sbin/voldisk online accessname...
/sbin/voldisk rm accessname...
/sbin/voldisk list [disk...]
/sbin/voldisk clearimport accessname...
/sbin/voldisk check accessname...
The voldisk utility performs basic administrative operations on disks. Operations include initializing and replacing disks, as well as taking care of some book-keeping necessary for the disk model presented by the Logical Storage Manager.
The voldisk utility accesses disks based on disk access names, which are system-specific names that relate to disk addresses. For example, SCSI disk access names are usually of the form rznp, where rz is the device mnemonic for SCSI devices, n is the SCSI unit number, and p is the partition identifier (in the range a to h). All disk access names relate directly to device node names in the /dev directory.
The Logical Storage Manager maintains known disk device address information in a set of disk access records, which are stored in the rootdg disk group configuration. These records are named, based on the disk access name. These disk access records are normally used solely to identify which physical disks exist, based on disk IDs stored on the disks themselves. Operations for voldisk other than init and define require specification of defined disk access records.
Physical disks contain public regions, which are used for allocating subdisks. They can also contain private regions, which are used for storing private Logical Storage Manager information. Each private region contains exactly two copies of a disk header, which defines the unique disk ID, disk geometry information, and disk group association information. Two copies are created so that one copy can be lost (due to I/O failures), without losing the ability to use the disk. The primary copy of the disk header is stored in block zero of the private region. The alternate copy is stored within the first 256 sectors. If the primary copy is unreadable or unusable, the Logical Storage Manager will search the first 256 sectors of the private region for the alternate copy. The table of contents contains a linked list of blocks, pointed to by the disk header, that define additional structures in the private and public regions. The table of contents blocks define disk group configuration copy locations, log copy locations, and reserved regions carved from the public region. Each link block in the table of contents is replicated at the beginning and end of the private region. If the primary copy of any one link block is unreadable or unusable, the alternate copy of that link is used. A disk normally contains between zero and two disk group configuration copies, according to the number specified when the disk was initialized using the voldisk init operation (explained later). When a disk is added to a disk group, the disk group's persistent configuration records are written to each copy. For disks that are not associated with a disk group, the space allocated for configuration copies is unused. Each disk group requires at least one usable configuration copy. Preferably there should be at least four copies, allocated between at least two disks. This allows one disk to be lost totally, while still preserving sufficient redundancy for recovering from simple read failures. A disk normally contains between zero and two disk group log copies. The number of log copies is set to the same as the number of configuration copies for the disk as explained in the Configuration copies section above. These logs are written by the kernel when certain types of actions are performed: transaction commits, plex detaches resulting from I/O failures, total block-change-log failures, the first write to a volume, and volume closes. After a crash or a clean reboot, this log information is used to recover the state of a disk group just prior to the crash or reboot. Each disk group requires at least one usable disk group log copy. As with configuration copies, it is preferable to have at least four log copies, allocated between at least two disks.
The behavior of the voldisk utility depends upon the keyword specified as the first operand. Supported operations are: Initialize regions of a disk used by the Logical Storage Manager. This involves installing a disk header and writing an empty configuration on the disk. The accessname operand identifies the disk. Normally, this command will fail if the disk already contains an apparently valid disk header. The -f option can be used to override this and to force initialization of the disk. A disk that is a member of an imported disk group cannot be initialized.
Three disk types are provided with the Logical Storage Manager. The
default is a
type for disk access names without
a partition name, such as
rz3. If a partition name, such
rz3c, is supplied, then the default type becomes
The simplest disk type is nopriv, which defines a disk that has no private region, and that consists only of space for allocating subdisks. Configuration and log copies cannot be stored on such disks, and such disks do not support reserved regions defined with voldisk addregion. Also, such disks are not self identifying. Because nopriv disks are not self identifying, the Logical Storage Manager cannot track the movement of such disks on a SCSI chain or between controllers.
Do not initialize a new disk as a nopriv disk - this disk type is appropriate only for encapsulation of existing data.
To add a disk with no configuration database, set the nconfig attribute to 0 when initializing the disk.
nopriv devices are most useful for defining special devices (such as volatile RAM disks) that you wish to use with the Logical Storage Manager, but that can't store private regions. A RAM disk cannot store a meaningful private region, because data written to a RAM disk may not survive a reboot.
Initializing a nopriv device with voldisk init creates a disk access record in the rootdg configuration, but does not write to the disk. The disk ID for nopriv devices is stored in the disk access record in the rootdg configuration.
Attributes that can be used with the voldisk init and define operations for the nopriv device type are: The usable length of the device. This is required if there is no system-defined procedure for determining the disk length; otherwise, a suitable default will be computed. The offset within the device for the start of the usable region. This can be used if it is necessary to skip over some region reserved by the operating system. If an offset is specified, then the default disk length is adjusted accordingly. If this attribute is specified, the disk is considered to have volatile contents (i.e., the disk contents are not expected to remain consistent across a system reboot). Subdisks and plexes defined on disks with the volatile attribute will inherit that attribute. The volume start operation interprets volatile plexes as requiring a complete revive from other plexes in the same volume.
Two disk types are provided that support disk private regions: simple and sliced. The simple type presumes that the public and private regions are stored on the same disk partition, with the public region following the private region. The sliced type presumes that the public and private regions are stored on different disk partitions.
For the simple type, the partition is marked with disklabel tag LSMsimp. For the sliced type, then the public and private regions are in partitions with disklabel tags LSMpubl and LSMpriv, respectively.
Attributes that can be defined with voldisk define for simple or sliced types are: Define the partition number to use for the public partition. This can be used only with the sliced type. Define the partition number to use for the private partition. This can be used only with the sliced type. Specify the offset from the beginning of the partition containing the private region to the beginning of the private region. This defaults to zero for both simple and sliced types. It is strongly advised that this option never be used unless absolutely necessary. Most information for disks can be determined from the disk header stored at the beginning of the private region. The private region offset cannot be determined from the disk. As a result, specifying a private region offset adds an undesirable dependence between a disk access record and a specific physical disk.
In addition to the above attributes,
takes the following attributes:
Specify the length of the public region. If this is not specified,
then the length of the private region is computed from available partition
table information. If no such information is available, a public region length
must be specified in this command. The default public region length is adjusted
to account for the private region, or for any specified public or private
Specify the offset from the beginning of the partition containing
the public region to the beginning of the public region. For the
type, this defaults to zero. For the
type, this defaults to the first block past the end of the private region.
Specify the length of the private region. If this is not specified,
then a default is chosen. For the
type, the default
is computed from available partition table information. For the
type, the default size is 512 blocks. With the
type, if no partition information is available, a private
region length must be specified in this command.
The number of configuration copies to store on the disk. The
number of configuration copies should be the same as the number of log regions.
This defaults to 1. This can be set to 0 to indicate that no configurations
will be stored on the disk. It is reasonable to set this to 1 for disk groups
that contain three or more disks. This would allow either more configuration
records or a smaller reserved private region. In disk groups with more than
8 disks, it may be reasonable to set
to zero for
some disks, so that space for configuration copies is allocated only on some
to zero improves the performance
of LSM configuration updates and reduces the time required to import a disk
The size to reserve for each copy of the configuration stored
on the disk. The default size will be based on the size of the private area
and the number of configuration copies requested, and will leave some space
free for uses other than the configuration copies.
The number of log regions to allocate on the disk. The number
of log regions should be the same as the number of configuration copies. Logs
regions are used for storing any plex detaches that happen within the disk
group. This number defaults to 1. It may be desirable to reduce this number
to 0 on some disks, if you have disk groups with large numbers of disks. However,
at least one valid log copy (preferably at least four, two copies each on
two drives) must be usable for a disk group to be usable.
The size to reserve in the private region for each log region.
This size limits the number of kernel-initiated detach operations that can
be logged against the disk group. The default is about 15% of the size of
the configuration copies. It is advised that the log sizes be kept as 15%
of the configuration copy size.
volintro(8), vold(8), voldg(8), volume(8)