/etc/dkconfig -cdefilpsTuUy vdisk_device ...
/etc/dkconfig -h vdisk_device ...
/etc/dkconfig -o vdisk_device ...
/etc/dkconfig -O piece_number vdisk_device ...
/etc/dkconfig -r vdisk_device ...
/etc/dkconfig -R vdisk_device ...
/etc/dkconfig -v vdisk_device ...
/etc/dkconfig -V vdisk_device ...
/etc/dkconfig -z vdisk_device ...
/etc/dkconfig -Z partition
The Virtual Disk Manager provides a convenient graphical front-end to dkconfig. It is recommended that you use this interface to administer your virtual disks. If you need to configure more complicated nested virtual disk arrays than the Virtual Disk Manager provides, you must add the new definitions to /etc/dktab and run dkconfig manually.
dkconfig reads /etc/dktab to obtain virtual disk configuration information in the same way that mount(ADM) reads /etc/mnttab to obtain mountable filesystem information. The virtual disk definitions in /etc/dktab are used by dkconfig both to configure virtual disks and to list the current virtual disk configuration.
If you alter the definition of a virtual disk while it is configured, this initiates an online reconfiguration which rearranges the virtual disk's data to fit the new definition. If you alter a virtual disk's definition while it is offline, the virtual disk subsystem in the operating system kernel is not aware that the definition has changed. When the virtual disk is configured again, the kernel acts as if the virtual disk has always been configured in the new way, and does not attempt to rearrange the virtual disk's data to fit the new definition. In this case the former data in the virtual disk is no longer usable and any filesystem or database structures in it must be re-initialized. Therefore, you should reconfigure virtual disks while they are already configured unless the existing data is no longer wanted or the data has been backed up and can be restored under the new configuration.
When multiple virtual disks are configured (using the -a option), dkconfig checks for any overlap with the partition reserved area (including the bad track/bad block table), other virtual disk definitions in /etc/dktab, and virtual disks defined in the kernel. When defining a virtual disk, you should also check that its pieces do not overlap already existing filesystem divisions, or raw database storage areas.
Once a virtual disk is in use, care must be taken not to corrupt the disk data. For example, a virtual disk cannot be unconfigured if it contains a mounted filesystem. An EBUSY (device busy) error will be returned if any attempt is made to unconfigure a busy virtual disk.
If any virtual disks defined in /etc/dktab contain filesystems, dkconfig must be executed prior to fsck(ADM) or mount(ADM), since a virtual disk must be configured before it can be used. This happens automatically as part of the process of going to multiuser mode; the /etc/inittab script invokes dkconfig to perform disk configuration as specified in /etc/dktab. The /etc/rc2.d scripts are then executed, which performs the filesystem checking. However, to check virtual disk filesystems in single-user mode, enter dkconfig -ac to configure the virtual disk devices before invoking fsck. Attempting to execute fsck on a virtual disk filesystem before configuring it will cause an ENXIO (no such device or address) error.
Although dkconfig only accepts block device nodes (vdisk_device) as command-line arguments (as specified in /etc/dktab), the vdisk(HW) driver supports both block and character device nodes.
dkconfig understands the following options:
The -c and -u options perform virtual disk configuration and unconfiguration, analogous to the filesystem mounting and unmounting services of mount(ADM) and umount(ADM).
Because most applications always perform a data read before a write, the state of the data and parity can be detected before any writing is done. In the event of a system crash, parity is presumed to be OUT-OF-DATE (OOD) as the data and parity are likely to be inconsistent. In this case, with the restore functionality enabled, consistency will be restored when the system is rebooted.
However, in a minority of situations, for example, when the swap device is being used as a mirror virtual disk, data is first written to the virtual disk before any reads are performed (after a system crash). By first performing a data write which includes a new parity calculation, the data and parity are updated and made consistent. This saves time and system resources as you do not now need to perform a full restore on the whole disk. To achieve this, you need to disable the restore functionality for this virtual disk. Also, this is only applicable where a system reboot is to be performed.
NOTE: If a piece is in the OUT-OF-SERVICE (OOS) state on a virtual disk with the restore disabled, you will need to re-enable the restore functionality before the piece can be brought back into service. Also, when an array is initially configured, the parity is always set to the OUT-OF-DATE state. Under normal circumstances, disabling the restore functionality will have the effect of changing this to the UP-TO-DATE state: disabled restore on a write-first application (swap device) as described above implies a parity update will be performed at the time of the writing. However, since this condition is only considered during system booting, the OUT-OF-DATE state remains unchanged. To change this, you will need to either reboot the system to meet the condition described earlier or use the -r option to force a restore on the whole disk.
Use the -v option (verify) to check if parity is UP-TO-DATE for the entire array (not just the parts which have been written to). If inconsistencies are found between the data and the parity, the array will be marked as having OUT-OF-DATE parity. When an array is marked as this, no parity will be generated on writes (regardless of whether the restore has been disabled or not).
The I/O statistics listed by the -ls
option are used to determine if I/O requests are
distributed fairly evenly across physical disks. If they are not,
the virtual disk cluster size should be reconfigured. The
-ls option can also be used to determine the
status of an array or mirror virtual disk piece. There are
four possible states. If the I/O count is
present the piece is ACTIVE. If a disk piece is
marked OUT-OF-SERVICE, the drive needs to be
repaired. If a disk piece is marked OUT-OF-DATE,
parity needs to be recreated (restored),
and, if a piece is marked
spare, it is the
configured hot spare.
If the -a option is given, dkconfig lists the status of all disks defined in /etc/dktab except the configuration database (vdisk0).
If the -s option is given, dkconfig describes each piece of the virtual disk.
The performance statistics may be used to identify hot spots and may also be used to determine if the virtual disk configuration should be reconfigured to another virtual disk type.
If the -a option is given, performance statistics are displayed for all disks defined in /etc/dktab.
If the -s option is given, performance statistics are also displayed for each piece of the virtual configuration.
If the -T option is given, dkconfig displays performance statistics reflecting the usage of the vdisk driver's resources. This allows you to modify the appropriate kernel tunables.
See ``Tuning virtual disk performance'' in the Performance Guide for more information.
See also the description of the -c (configure) option.
The -V option provides a
corrective verify operation.
The verify operation repairs
parity data on arrays and redundant data on mirrors
The mkdev hd command uses this option when adding new hard disks to avoid the risk that random values could be used for timestamps.
A virtual disk array or mirror will remain configured if it was taken offline while an application was still running. Before the data can be restored, the virtual disk must first be unconfigured using dkconfig -u, then configured again using dkconfig -cf to reinitialize the timestamps, and dkconfig -r to restore parity data.
When performing online reconfigurations, which includes changing the cluster size, piece size or number of pieces, the specified cluster size may not always be allowed. To simplify the reconfiguration process, select cluster sizes only from the set 2, 4, 8, 16, 32, 64 and 128, and select piece lengths which are multiples of 128 (where the cluster size is also being changed). In this case, all reconfigurations will be valid. Note that these values may not give the best I/O performance.
Some reconfiguration operations involving changing virtual
disk types in the configuration may require a larger
cluster size to be selected before the specified operation
can be performed. If needed, another online operation can be
performed to return the cluster size to its desired size.
If vdisk0 is not configured, only the /etc/dktab file provides virtual disk configuration information. Because of this, its integrity must be assured at all times.
Cluster size (n
) exceeds Length (m
Unequal Lengths (n
) exceeds physical partition size (m
) is not a multiple of 2 blocks
piece definition lines
Invalid number of pieces (maximum isn
Rest of file ignored
ignorekeyword was encountered in the /etc/dktab file.
Print a short summary list of all the current virtual disk
Print a detailed list of the current virtual disk configuration:
Print a detailed description of virtual disk vdisk1:
/etc/dkconfig -ls /dev/dsk/vdisk1
Print a short description of the first four virtual disks:
/etc/dkconfig -l /dev/dsk/vdisk[1-4]
Unconfigure all virtual disks defined in /etc/dktab:
Configure and initialize an array virtual disk vdisk2:
/etc/dkconfig -cf /dev/dsk/vdisk2
Force disk piece in virtual disk vdisk2 OUT-OF-SERVICE:
/etc/dkconfig -o /dev/dsk/vdisk2
Restore the parity information on an array virtual disk vdisk2:
/etc/dkconfig -r /dev/dsk/vdisk2
Unconfigure virtual disk vdisk2:
/etc/dkconfig -u /dev/dsk/vdisk2
Regenerate the /etc/dktab file from vdisk0
(the configuration database):
/etc/dkconfig -g > /etc/dktab
``Administering virtual disks'' in the System Administration Guide