Veritas Volume Manager 5.0 Release Notes (5900-0593, March 2010)

Veritas Volume Manager 5.0 Release Notes
Known Issues
Chapter 128
Volumes not started following a reboot
During very fast boots on a system with many volumes, vxconfigd may not be able to
auto-import all of the disk groups by the time vxrecover-s is run to start the volumes. As
a result, some volumes may not be started when an application starts after reboot.
Workaround: Check the state of the volumes before starting the application, or place a
sleep (sleep sec) before the last invocation of vxrecover. [i14450]
Forcibly starting a volume
The vxrecover command starts a volume only if it has at least one plex that is in the
ACTIVE or CLEAN state and is not marked STALE, IOFAIL, REMOVED, or NODAREC. If such a
plex is not found, VxVM assumes that the volume no longer contains valid up-to-date
data, so the volume is not started automatically. A plex can be marked STALE or IOFAIL as
a result of a disk failure or an I/O failure. In such cases, to force the volume to start, use
the following command:
# vxvol -f start volume
However, try to determine what caused the problem before you run this command. It is
likely that the volume needs to be restored from backup, and it is also possible that the
disk needs to be replaced. [i14915]
Failure of memory allocation
On machines with very small amounts of memory (32 megabytes or less), under heavy I/O
stress conditions against high memory usage volumes (such as RAID-5 volumes), a
situation occurs where the system cannot allocate physical memory pages any more.
Number of columns in a RAID-5 ISP volume
If an ISP volume is created with the RAID-5 capability, the parameters ncols and
nmaxcols refer only to the number of data columns, and do not include the parity column.
For this reason, the actual number of columns that are created in such a volume is always
one more than the number specified.
Disk Space on Root File System
The /etc/vx/cbr file that is backed up during disk group imports and configuration
changes is larger than in past releases. This means that it is possible to encounter file
system full errors on the root file system while running commands such as vxdg import.
The workaround is to size the root file system (/) appropriately, by allocating 64MB for
every disk group in use on the system.
Volumes in Use During Disk Group Deport