Disk Devices

When performing disk administration, it is important to understand the difference between a disk name and a device name.

When a disk is placed under VxVM control, a VM disk is assigned to it. You can define a symbolic disk name (also known as a disk media name) to refer to a VM disk for the purposes of administration. A disk name can be up to 31 characters long. If you do not assign a disk name, it defaults to diskgroup## where diskgroup is the name of the disk group to which the disk is being added, and ## is a sequence number. Your system may use device names that differ from those given in the examples.

The device name (sometimes referred to as devname or disk access name) defines the name of a disk device as it is known to the operating system. Such devices are usually, but not always, located in the /dev/[r]dsk directories. Devices that are specific to hardware from certain vendors may use their own path name conventions.

VxVM recreates disk devices, including those from the /dev/[r]dsk directories, as metadevices in the /dev/vx/[r]dmp directories. The dynamic multipathing (DMP) feature of VxVM uses these metadevices (or DMP nodes) to represent disks that can be accessed by more than one physical path, usually via different controllers. The number of access paths that are available depends on whether the disk is a single disk, or is part of a multiported disk array that is connected to a system.

You can use the vxdisk utility to display the paths subsumed by a metadevice, and to display the status of each path (for example, whether it is enabled or disabled). For more information, see Administering Dynamic Multipathing (DMP).

Device names may also be remapped as enclosure-based names as described in the following section.

Disk Device Naming in VxVM

Prior to VxVM 3.2, all disks were named according to the c#t#d# naming format used by the operating system. Fabric mode disks were not supported by VxVM. From VxVM 3.2 onward, there are two different methods of naming disk devices:

• c#t#d# Based Naming
• Enclosure Based Naming

c#t#d# Based Naming

In this naming scheme, all disk devices except fabric mode disks are named using the c#t#d# format.

The syntax of a device name is c#t#d#, where c# represents a controller on a host bus adapter, t# is the target controller ID, and d# identifies a disk on the target controller.

Fabric mode disk devices are named as follows:

• Disk in supported disk arrays are named using the enclosure name_# format. For example, disks in the supported disk array name FirstFloor are named FirstFloor_0, FirstFloor_1, FirstFloor_2 and so on. (You can use the vxdmpadm command to administer enclosure names.)
• Disks in the DISKS category (JBOD disks) are named using the Disk_# format.
• Disks in the OTHER_DISKS category (disks that are not multipathed by DMP) are named using the fabric_# format.

Enclosure Based Naming

Enclosure-based naming operates as follows:

• Devices with very long device names (for example, Fibre Channel devices that include worldwide name (WWN) identifiers) are always represented by enclosure-based names.
• All fabric or non-fabric disks in supported disk arrays are named using the enclosure_name_# format. For example, disks in the supported disk array, enggdept are named enggdept_0, enggdept_1, enggdept_2 and so on. (You can use the vxdmpadm command to administer enclosure names. See Administering DMP Using vxdmpadm and the vxdmpadm(1M) manual page for more information.)
• Disks in the DISKS category (JBOD disks) are named using the Disk_# format.
• Disks in the OTHER_DISKS category (disks that are not multipathed by DMP) are named as follows:
• Non-fabric disks are named using the c#t#d# format.
• Fabric disks are named using the fabric_# format.

See Changing the Disk-Naming Scheme for details of how to switch between the two naming schemes.

To display the native OS device names of a VM disk (such as mydg01), use the following command:

For information on how to rename an enclosure, see Renaming an Enclosure.

For a description of disk categories, see Disk Categories.

Private and Public Disk Regions

Most VM disks have two regions:

private region A small area where configuration information is stored. A disk header label, configuration records for VxVM objects (such as volumes, plexes and subdisks), and an intent log for the configuration database are stored here. The default private region size is 2048 blocks (2048 kilobytes), which is large enough to record the details of about 4000 VxVM objects in a disk group.

Under most circumstances, the default private region size should be sufficient. For administrative purposes, it is usually much simpler to create more disk groups that contain fewer volumes, or to split large disk groups into several smaller ones (as described in Splitting Disk Groups). If required, the value for the private region size may be overridden when you add or replace a disk using the vxdiskadm command.

Each disk that has a private region holds an entire copy of the configuration database for the disk group. The size of the configuration database for a disk group is limited by the size of the smallest copy of the configuration database on any of its member disks.

public region An area that covers the remainder of the disk, and which is used for the allocation of storage space to subdisks.

A disk's type identifies how VxVM accesses a disk, and how it manages the disk's private and public regions. The following disk access types are used by VxVM:

simple The public and private regions are on the same disk area (with the public area following the private area).

nopriv There is no private region (only a public region for allocating subdisks). This is the simplest disk type consisting only of space for allocating subdisks. Such disks are most useful for defining special devices (such as RAM disks, if supported) on which private region data would not persist between reboots. They can also be used to encapsulate disks where there is insufficient room for a private region. The disks cannot store configuration and log copies, and they do not support the use of the vxdisk addregion command to define reserved regions. VxVM cannot track the movement of nopriv disks on a SCSI chain or between controllers.

auto When the vxconfigd daemon is started, VxVM obtains a list of known disk device addresses from the operating system and configures disk access records for them automatically.

Auto-configured disks (with disk access type auto) support the following disk formats:

cdsdisk The disk is formatted as a Cross-platform Data Sharing (CDS) disk that is suitable for moving between different operating systems. This is the default format for disks that are not used to boot the system.Typically, most disks on a system are configured as this disk type. However, it is not a suitable format for boot, root or swap disks, for mirrors or hot-relocation spares of such disks, or for EFI disks.

hpdisk The disk is formatted as a simple disk. This format can be applied to disks that are used to boot the system. The disk can be converted to a CDS disk if it was not initialized for use as a boot disk.

See the vxcdsconvert(1M) manual page for information about the utility that you can use to convert disks to the cdsdisk format.

By default, auto-configured disks are formatted as cdsdisk disks when they are initialized for use with VxVM. You can change the default format by using the vxdiskadm(1M) command to update the /etc/default/vxdisk defaults file as described in Displaying and Changing Default Disk Layout Attributes. See the vxdisk(1M) manual page for details of the usage of this file, and for more information about disk types and their configuration.