These release notes support ptx®/SVM V2.2.1, which is a powerful tool for managing disk-drive usage and disk space. Read this document before you install or run this release of ptx/SVM.
This version of ptx/SVM can be used with the following products:
See the DYNIX/ptx and Layered Products Software Installation Release Notes for further software product compatibility information.
This release of ptx/SVM contains fixes for the following software defects:
(239050) The clusterid was changed when vxdctl was used to change the hostname.
(247055) The vxdiskadm OLR Procedure does not rebuild plexes and subdisks.
(248443) During resilvering, transaction performance was very slow.
(249737) Conflict messages appeared when ptx/SVM was deinstalled through ptx/INSTALL.
(251150) When a joined slave left the cluster, the CCIs on the master were marked as "down." However, the imd did not notify the client the CCIs were down, and the master's configd continued to maintain portals on its CCIs, listening for connections.
(250861) The D98svmcleanup script caused the system to panic when ptx/SVM sharing was disabled.
(249641) The slave kernel panicked after it committed the shared configuration from the master into its permanent list.
(249594) dg_import_finish committed a NULL transaction.
(248817) When a cluster CCI was down, the ptx/SVM slave vxconfigd spun.
(248773) A confusing error message appeared during an attempt to change the volume usage type to root.
(248346) An MMU fault occurred in volsiodone when parent->sio_ops->sop_childdone was NULL.
(247864) vxconfigd was unable to distinguish between a program error and a node shutdown, resulting in delays during a regular node shutdown.
(247221) The message Previous %s volume '%s' renamed '%s' from autostart.c was always truncated when it appeared on the console.
(246996) vol_mv_detach_mirror did not check correctly for a full klog.
(246451) I/O errors related to klog regions were not logged.
(245565) When fifty or more plex attaches were attempted, they hung, and caused all subsequent ptx/SVM commands to hang.
(243982) ptx/SVM issued a devsw_lookup() operation for every I/O, resulting in I/O performance problems.
(242408) vxconfigd did not see CCI "up" events, potentially resulting in broken shared transactions.
(240131) On a slave node, vxdg created shared disk groups with the same base minor number as private disk groups.
(239445) An attempt to assign a new minor number to a shared disk group that had the same minor number as a private disk group failed.
(237181) REMOTE commands did not handle CCI failures gracefully because they forced TCP/IP timeouts before attempting to use alternate IP interfaces.
(235835) An entry for ROOTVOL did not exist in /dev/vx/dsk and /dev/vx/rdsk.
The ptx/SVM V2.2.0 release contained fixes for the following software defects:
(249124) An error occurred when ptx/SVM tried to attach a plex onto SWAPVOL.
(248262, 229395) diskid could not open a diagnostic device for shared disks in private disk groups.
(248184) No documentation existed on how to replace failed disks that contained ptx/SVM objects. Appendix C of the ptx/SVM Administration Guide now contains a section entitled "Replacing Failed Disks: Command-Line Procedure."
(247979, 245720) The master node was tracking an excessive number of stale clients that were leftover from join attempts.
(247969) During failover, volumes in a two-node cluster would become stranded in the SYNC state and would only resynchronize when forced to or when all nodes were rebooted.
(247645) Private volumes were not enabled if the master died during a vxconfigd join process.
(247587) vxconfigd on a node that was becoming the master dumped core (thereby preventing the slave from joining), and placed the master in single-user mode.
(247527) vxconfigd could not be restarted from the command line after installation of ptx/SVM. vxconfigd reported no error that it could not start.
(247448) ptx/SVM did not tag I/O to private volumes on shareable spindles.
(247124) A shared disk group became disabled after master takeover if a volume failed to resynchronize after a vxrecover operation.
(247067) The GLOCK protocol was liable to hang after master takeover if the GLOCK was partially through the protocol when the original master died.
(246967, 242311) Hot sparing failed on simple disks and disabled the disk group. Hot sparing now works.
(246851) vxconfigd on the slave node failed during a join protocol.
(246775) ptx/SVM failed to start any volumes if a mirrored volume with norecov set contained a plex with a disk that was missing.
(246033, 245738) When private disk groups on shared disks were deported, warnings about "Invalid device close flags" were sent to the ktlog.
(245633) vxconfigd could not be restarted on the master without causing the slave's vxconfigd to fail.
(245623) pfmt error messages contained "\" for the line separator.
(245105, 244765, 231649) vxencap was liable to overwrite data; it is no longer part of ptx/SVM.
(245018) Several ptx/SVM scripts contained change-log entries.
(244965) A ptx/SVM error message on a clustered system was misleading.
(244861) The vxstat -b option was not documented in the vxstat man page.
(244264) Private disk group failover did not safely handle quorum loss.
(244224) The vxdg man page incorrectly stated that minor numbers range up to 16 bits; this has been changed to 22.
(244172) A panic occurred when vxstat -b was run.
(244037) DYNIX/ptx and ptx/SVM did not agree on the real size of SWAPVOL, resulting in a system panic.
(243682) With ptx/SVM sharing disabled, the /etc/rc2.d/S03svm-awaitjoin script waited forever, preventing the system from going to multiuser mode. The script did not recognize the state of ptx/SVM where sharing was intentionally disabled.
(243342) On DETACH IOFAIL of a mirrored plex, ORACLE failed with an I/O error.
(242492) Adding a ptx/SVM disk resulted in "disk log too small for configuration" error.
(241771) vxconfigd dumped core due to a divide by 0 during a commit().
(241380) The vxdctl man page did not include a description of the -C option.
(241278) When vxconfigd was restarted, it caused vxnotify to stop.
(241247) The vxedit command returned an incorrect error message.
(240518) ptx/SVM needed restrictions on vxdg and vxdisk "force" options. ptx/SVM now provides safeguards to prevent these commands from succeeding when they are not desirable.
(239897) vxmake -d created volumes with minor numbers from the description file, which didn't necessary match their true minor numbers.
(239445) vxdg reminor failed when issued on a shared disk group.
(238877) While the system was rebooting after a panic, the vxrecover error Arg list too long occurred if a disk group contained a list of volumes larger than MAXPATHLEN. Subsequently, the mountall script failed and the system was placed in single-user mode. The volumes needed to be started manually to get the system to run-level 2.
(238325) The vxassist man page incorrectly stated that s (controller) was an acceptable value for the mirror= field.
(237459) ptx/SVM did not always purge stale disk access records.
(237222) In an effort to control the number of resilvering operations attempted by vxrecover at a time, a new option, -t N, has been added to vxrecover so that you can specify no more than 30 resilvering operations at a time. For more information about this option, see the vxrecover(1M) man page.
(236853) ptx/SVM tried to recreate devices multiple times, resulting in error messages that showed up on the console and in the log.
(236609) vxassist failed to create a striped, mirrored volume with a log on a cluster.
(235530) If the "noattach" option was set on a volume and if that volume had a stale plex, when the volume was started the stale plex was not attached to the volume. The plex continued to be STALE and DISABLED.
(233342) vxresize failed to change the size of an efs filesystem.
(232357) An incorrect error message was returned when a hot-spare bit was set on a nopriv disk.
(231649, 245105) vxencap failed when invoked on a non-bootable device. vxencap has been removed from ptx/SVM.
(229395) The /etc/diskid disk flash option failed if a disk was under ptx/SVM control.
(228725) Under certain failure conditions, dg_free was called twice for the same disk group.
(226734) vxdg dumped core when initializing a disk group with a numeric minor.
(223835) vxvol returned "Arg list too long" with the startall option.
This release of ptx/SVM contains a considerable amount of new functionality and significant configuration differences from ptx/SVM V1.x. If you are currently running ptx/SVM V1.x, do not install DYNIX/ptx V4.5.x or any layered products until you have contacted Customer Support.
If you have already upgraded to ptx/SVM V2.0.2, V2.0.3, V2.1.1, V2.1.2, V2.1.3, or V2.2.0, you can install this release of ptx/SVM along with DYNIX/ptx and any other layered software products through a single installation process. TheDYNIX/ptx and Layered Products Software Installation Release Notes tell how to use this process to install all NUMA-Q software.
Although it is not necessary to deinstall ptx/SVM before installing a new version of the software, should you wish to deinstall ptx/SVM, the automatic deinstallation process through the ptx/ADMIN menu system will fail because root and swap volumes are in use. Follow these steps before deinstalling ptx/SVM through ptx/ADMIN to ensure the deinstallation will succeed:
ATTENTION Issuing the following command will disable all volumes. Make sure your system does not depend on any volumes for filesystems, swap space, or other uses that your system requires to boot.
Prevent vxconfigd from starting during the boot process:
# touch /etc/vx/reconfig.d/state.d/install-db
Disable the use of early-access volumes on the next reboot:
# bp /unix vol_disable_early_access_volumes 1
Reboot the system.
The following sections discuss important usage considerations with this release of ptx/SVM.
Because the ptx/SVM menu system, vxdiskadm, currently fails to work with shared disks (Problem Report #236943) and does not properly perform OLR of sliced and simple disks (Problem Report #242863), IBM NUMA-Q recommends that you do not use vxdiskadm.
ptx/SVM V2.x requires that every shareable private spindle have at least one private region. A shareable disk is one that is on the QCIC or Fibre Channel and that could be shared. Shareable spindles that are of type nopriv cannot be added to private disk groups, therefore, because nopriv disks do not contain private areas.
In order to place a shareable nopriv spindle under ptx/SVM control, you will have to re-partition the disk to create a type-8 slice on it for the private configuration database area. To determine if a disk is shareable, examine the output of the dumpconf -d command. Look for an "S" in the fifth column of the output. "S" signifies that a device is shareable.
If you wish to place a disk containing a VTOC driver under ptx/SVM control and use the disk in a cluster, then you must make an entry in each node's /etc/devtab file for the disk and issue the devbuild command on each of the nodes in the cluster.
If you build the VTOC driver for a disk on one node (where the disk will be recognized as a "sliced" or "nopriv" disk), but not on the other node(s) (where the disk will be recognized as a "simple" disk), then the ptx/SVM shared disk groups will not match across the cluster and you will not be able to use them.
IBM NUMA-Q has found that object manipulation performance in private disk groups in a cluster is significantly better than in shared disk groups. Use shared disk groups only when absolutely necessary (for data that must be shared among cluster nodes) to avoid incurring a performance penalty.
ptx/SVM lets you use the vxdg -k rmdisk medianame command to remove a disk media record even if the volume containing the disk is active. This operation is not recommended, especially if the data to be removed is not mirrored elsewhere. Should you use the vxdg -k rmdisk medianame command, use extra caution if the disk belongs to ROOTVOL, SWAPVOL, or a secondary swap volume. If you issue the command on a disk media record that is part of non-mirrored swap or a secondary swap volume, then the machine will crash or fail over.
The following ptx/SVM documentation is available online:
The ptx/SVM Quick Reference Card is available only in hard copy and is shipped with each order of ptx/SVM.
This section lists open problems in this release of ptx/SVM. The numbers in parentheses identify the problems in the problem-tracking system.
If you create a volume in rootdg with the same name as a disk group, that disk group cannot be imported automatically on subsequent reboots.
Workaround. Import the disk group manually with a different name, or rename the volume.
The command-line parser for vxdisk init ignores invalid values for loglen.
Workaround. None. Use only valid values for the loglen parameter.
The vxassist arguments maxgrow and maxsize were inadvertently omitted from the man page for vxassist.
The command vxassist [ -g diskgroup] maxgrow volume_name will tell you how large the volume could grow given the current available disks in the specified disk group (or in the root disk group, if no disk group is specified).
The command [vxassist -g diskgroup] maxsize will tell you how large the largest volume could be made in the specified disk group (or in the root disk group, if no disk group is specified).
Workaround. None.
By default, vxconfigd sends errors to the console. It should also send errors to a log file or through syslog.
Workaround. None.
The vxmake command limits the number of objects that can be created in a single invocation. The formula for determining the limits depends on the names of the objects involved as well as the kinds of objects and the values of some other fields in the objects. If the request fails with the message Configuration too large, you should try splitting the description file into two files and running vxmake twice.
When attempting to determine the size of the configuration database (private area) of a disk, a good rule of thumb is to allow about 400 bytes for each object. A 20,000 object database, for example, would require a minimum of 7800 blocks (1024-byte blocks).
Workaround. If the configuration database is undersized and you receive the message Not enough space in database, the problem affects only the disk group containing the database. To enlarge the database, make sure that all copies of the database are made larger by using the OLR procedure to remove the disks with small configuration areas and replace them with disks with larger configuration areas. This may mean that some data will have to be moved off of the disk in order to make room for the larger private area.
If, while vxrecover is running, you attempt to deport disk groups on which vxrecover still intends to perform recovery, vxrecover will return messages saying that it can't find volumes on the disk groups you are attempting to deport.
Workaround. Although the messages are harmless, you can avoid receiving them by not deporting disk groups until recovery is complete (when no volumes are in the SYNC or NEEDSYNC state).
The vxstat command is restricted for use by the root user only.
Workaround. None.
Mirrored volumes cannot detect any tampering done to them outside of ptx/SVM control. The tampering can be accomplished by modifying the underlying devices before ptx/SVM is started, such as from the stand-alone kernel on NUMA-Q 2000 systems. In the case of the root volume, remounting the root filesystem so that it is writable from either the stand-alone kernel or single-user mode will undetectably render the volume out of sync such that successive reads of the same area will return different results.
Workaround. Before tampering with any component of a ptx/SVM volume, modify the volume so that it is not mirrored. Never use the /stand/sci/mrootsau script (or any other method for remounting the root read/write) on a system with a mirrored root.
Automatic deinstallation of ptx/SVM (through the ptx/ADMIN® menu system) fails because root and swap volumes are in use.
Workaround. Before attempting to deinstall ptx/SVM, execute the commands touch /etc/vx/reconfig.d/state.d/install-db and bp /unix vol_disable_early_access_volumes 1 and reboot the system.
ATTENTION Issuing these commands will disable all volumes. Make sure your system does not depend on any volumes for filesystems, swap space, or other uses that your system requires to boot.
ptx/SVM allows you to attach a plex containing more than one subdisk to ROOTVOL.
Workaround. Attach only one subdisk to a plex in ROOTVOL.
The vxdiskadm option to offline a disk does not work.
Workaround. Use the devctl -d -D command to offline a disk.
When ptx/SVM is installed but not enabled, vxiod processes are started anyway.
Workaround. This is expected behavior and there is no workaround.
When creating a volume with vxassist, if the length of the volume is not divisible by the number of subdisks to be associated with the volume, then vxassist will create a volume whose length is shorter than the length of the plex (sum of the subdisks).
Workaround. Create volumes where the length is divisible by the number of subdisks. If the volume is striped, create stripe widths divisible by the number of subdisks.
ptx/SVM support for dumpcfg (/etc/dumpcfg.d/vx) does not correctly handle disk groups other than rootdg.
Workaround. None.
The vxconfigd -k command may fail to reimport all disk groups.
Workaround. Import the disk groups manually.
If a disk in a subdisk fails and you try to create a plex with that subdisk with vxmake, vxconfigd will terminate and hang vxmake.
Workaround. None.
The vxdiskadm OLR option fails on shared disks
Workaround. None.
When a volume is in an unstartable state because a disk is missing, vxvol start will fail and return no error message, leading the user to believe the volume started successfully.
Workaround. None.
Once a single-plex volume is in an ENABLED/SYNC state (accessible but in read/writeback mode), there is no action available that removes the SYNC state.
Workaround. If an unmirrored volume is in the ENABLED/SYNC state and you want to remove the SYNC state, stop the volume and restart it.
The following message may appear after a node goes down, while a vxplex att operation is in progress, or if a vxplex/vxrecover operation is killed locally:
vxplex -g diskgroup det plex
vxvm:vxplex: ERROR: Volume volume is locked by another utility
Workaround. Clear the "tutil0" field of the volume and plex with the following commands:
# vxmend clear tutil0 volume
# vxmend clear tutil0 plex
When a mirrored volume is stopped with vxvol -o force stop, a resynchronization is started on the volume. If the volume is forced to stop again, the offset counter remains partway through the volume when the volume is restarted again. The offset counter should be reset to zero.
Workaround. Do not use the -o force option to stop mirrored volumes. If you use the -o force option and the offset is not returned to zero, reboot the system to return the offset to zero.
Problems can arise when the vxconfigd -k command is issued on the slave node and, while the command is processing, a shared disk group is deported from the master. When the slave finishes with the new vxconfigd, it reports the shared disk group is disabled but imported. The master does not show the shared disk group as imported. You cannot deport the disk group because the master does not see it. You cannot import it again because the slave cannot see one or more of the disks in the disk group.
Workaround. Restart vxconfigd on the slave again.
If you force a disk into a disk group with vxdisk -f, but the disk previously belonged to a different disk group, the disk can end up belonging to both disk groups.
Workaround. Do not use the -f (force) option when adding a disk to a disk group.
Asynchronous reads at 32 KB I/O size cause performance problems because the system is set up for reads at 128 KB I/O size.
Workaround. None.
It is possible to create a shared disk group on the master node that has the same base minor number as a private disk group on the slave node.
Workaround. Deport the shared disk group with the same base minor number as the private disk group and remake it.
When you run vxdg free on a slave node, only data concerning the rootdg and shared disk groups is returned.
Workaround. None.
When both cluster nodes have a private disk group with the same name that contains shared disks, they receive a warning message when the nodes are booted because although the group name matches, the disk IDs point to the wrong side.
Workaround. If using shared disks in private disk groups, you should not have the same disk group name on both nodes. Otherwise, you can just ignore the error message.
When you replace a mirrored disk that is part of a two-disk disk group, ptx/SVM does not recognize that this has occurred and data may become corrupted.
Workaround. None.
If quorum is lost and then regained, resilvering seems to hang.
Workaround. Stop the resilvering and restart it manually.
The S03reconfig script outputs the following incorrect error message:
vxvm:vxdisk: TO FIX: Usage:
vxdisk [-f] [-g diskgroup] [-qs] list [disk ...]
Workaround. Ignore the message.
If you change the name of a shared disk group and the master node panics, the new master may only partially pick up the name change. This may make the output of vxdisk list and vxdg list confusing.
Workaround. Deport the disk group from the new master and reimport it before bringing the node that is down back into the cluster.
vxdiskadm fails to execute an OLR procedure on a sliced disk or on a simple disk that is in a state of NODEVICE, and gives no indication of the failure.
Workaround. Do not use svmadmin to perform OLR. Use the manual procedure described in the ptx/SVM Administration Guide.
When you issue the vxdisk -f init disk command to create a disk access record for a disk (if one does not already exist on the disk), you will be returned the following error:
vxvm:vxdisk: ERROR: Device disk: No DA record exists in configuration
Workaround. Use vxdctl enable to create a disk access record for the disk.
If a mirrored volume is in read-writeback mode and n-1 plexes are offlined before the resynchronization operation is completed, the volume is left in either the NEEDSYNC or the SYNC state.
Workaround. Stop and restart the volume.
If you create a dirty-region log (DRL) subdisk on a shared volume and the master crashes when the system comes back up, the system will hang in S03svm-awaitjoin upon reboot.
Workaround. Do not use dirty-region logging on shared volumes.
The vxtrace command only tracks local I/O; it does not work clusterwide.
Workaround. Use vxtrace on each individual node, or just for local I/O traffic on one node.
If you create the rootdg prior to setting the node name on a system, ptx/SVM will have problems importing disk groups.
Workaround. Set the system's node name correctly before creating the root disk group. See the section entitled "Start the ptx/SVM Configuration Daemon" in Chapter 2 of the ptx/SVM Administration Guide for information on how to set up the root disk group.
If a klog update fails for any reason on all private areas belonging to a disk group, the system panics.
Workaround. Design the object configuration for each disk group such that if any of piece of hardware fails, you should still be able to access at least one private area on a disk belonging to the shared disk group.
When you use disks that are not shareable among all cluster nodes to create shared disk groups in a cluster where only one node is active, other nodes will be prevented from subsequent ly joining the cluster. They cannot see the disk when they attempt to join the cluster.
Workaround. Try removing the local disks from the disk group. If that is not possible, then deport the disk group from the master so that the remaining nodes can join the cluster.
Manually resynching shared volumes from the slave is possible but not recommended. There are two reasons for this. One is there is a slight performance cost, since the master must still be involved in some aspects of the resynching. Two is that if the master dies while resynching, the resynching will hang until the slave becomes the master. If, during this time, the slave also dies, it is possible these volumes will be left in read/writeback mode, incurring no data loss but a moderate performance penalty.
Workaround. Rebooting both nodes can clear the condition in some cases, but can be disruptive. In other cases, it may still be necessary to manually remove and recreate the volumes to clear this state. Removing and recreating these volumes without disrupting normal operation may be difficult or in some cases impossible; customers may need to call Customer Support for assistance.
Do not use vxassist to create a mirror on the same disk as the first plex. vxassist will return the following error:
# vxassist mirror ROOTVOL disk
vxvm:vxassist: ERROR: Cannot allocate space to mirror nnnnnn block volume
Workaround. To use vxassist, specify a different spindle. Otherwise, use vxmake.
The vxassist man page should state that the snapstart and snapshot options do not work for alternate root partitions.
Workaround. None. Mirror ROOTVOL instead.
The following confusing error message appears when an fsgen volume is reset to type root:
# vxedit set use_type=root volume
vxvm:vxedit: ERROR: Volume volume usage type is root: not gen or fsgen
This error message is confusing because the volume's usage type is fsgen.
Workaround . None.
A plex cannot contain subdisks that have punctuation (such as plus signs or apostrophes) in their names. (Underscores are acceptable.)
Workaround. None.
A disk with no VTOC can be specifically defined as type "nopriv" (for example, vxdisk define sd5 type=nopriv). This disk could then be added to a shared disk group (where sd5 is on a shared spindle) with vxdg -g shareddg adddisk sd5, where shareddg is a previously defined shared disk group. However, a "nopriv" ptx/SVM disk has no private area to store the configuration database, and this could lead to data corruption since the disk can be added to different disk groups at different points in time.
ATTENTION The default for a vxdisk define operation is to create a disk of type "simple". So a vxdisk define sd5 command will create sd5 to be a "simple" ptx/SVM disk.
Another manifestation of this problem is that a "nopriv" ptx/SVM disk (on a disk which has a VTOC on it) on a non-shared spindle can be added to different private disk groups at different points in time when no other partition from the same disk is added to the shared disk group. This could also lead to data corruption.
Workaround. None. Avoid defining disks on shared spindles (with no VTOCs) as "nopriv" ptx/SVM disks and then adding these disks to different disk groups at different points in time. Also avoid adding "nopriv" ptx/SVM disks (with VTOCs on non-shared spindles) to different disk groups at different points in time when no other partition from the same disk is added to the disk group. Either of these actions could lead to data corruption.
The disk OLR procedure documented in Appendix C of the ptx/SVM Administration Guide fails when the replacement disk already contains a ptx/SVM private area. That is, the replacement disk was used in a private disk group.
Workaround. During the vxdctl enable step of the procedure, issue vxdctl enable twice.
ptx/SVM volumes, except for ROOTVOL and SWAPVOL, are not available in single-user mode during the boot process.
The S09logicalroot startup script attempts to mount /var/ees on the devices specified in /etc/vfstab file. If the devices pointed to them are volumes, the mount will fail. This can lead to problems during an upgrade of ptx/SVM software if the system is configured to use volumes as mount points /var/ees.
Workaround. Do not specify volumes as mount point of /var/ees in /etc/vfstab file. Disk partition devices can be specified.
Before a software upgrade, move all data in the volume to a contiguous partition, and then change the mount point to point to the partition.
Disks of type "nopriv" cannot be used for hot sparing. When a disk encounters a persistent I/O failure, ptx/SVM determines that the disk has failed by trying to update the private area of the disk with the failure information. If the update to the private area fails, then ptx/SVM determines that the disk has failed and then hot spares the disk. Since "nopriv" disks have no private area, the hot sparing procotol has no way of validating that the disk has failed.
Additionally, since ptx/SVM requires that all spare disks contain a private area onto which any lost private data can be restored, "nopriv" disks cannot be designated as hot-spare disks.
Workaround. None. Do not designate "nopriv" disks as hot-spare disks.
The vxconfigd(1M) man page does not specify the name of the file that is used when you select the -x option.
Workaround. None.