InfoScale™ 9.0 Troubleshooting Guide - AIX
- Introduction
- Section I. Troubleshooting Veritas File System
- Section II. Troubleshooting Veritas Volume Manager
- Recovering from hardware failure
- Failures on RAID-5 volumes
- Recovery from failure of a DCO volume
- Recovering from instant snapshot failure
- Recovering from failed vxresize operation
- Recovering from boot disk failure
- Managing commands, tasks, and transactions
- Backing up and restoring disk group configurations
- Troubleshooting issues with importing disk groups
- Recovering from CDS errors
- Logging and error messages
- Troubleshooting Veritas Volume Replicator
- Recovery from configuration errors
- Errors during an RLINK attach
- Errors during modification of an RVG
- Recovery on the Primary or Secondary
- Recovering from Primary data volume error
- Primary SRL volume error cleanup and restart
- Primary SRL header error cleanup and recovery
- Secondary data volume error cleanup and recovery
- Recovering from hardware failure
- Section III. Troubleshooting Dynamic Multi-Pathing
- Section IV. Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting CFS
- Troubleshooting fenced configurations
- Troubleshooting Cluster Volume Manager in Arctera InfoScale products clusters
- Troubleshooting Storage Foundation Cluster File System High Availability
- Section V. Troubleshooting Cluster Server
- Troubleshooting and recovery for VCS
- VCS message logging
- Gathering VCS information for support analysis
- Troubleshooting the VCS engine
- Troubleshooting Low Latency Transport (LLT)
- Troubleshooting Group Membership Services/Atomic Broadcast (GAB)
- Troubleshooting VCS startup
- Troubleshooting service groups
- Troubleshooting resources
- Troubleshooting I/O fencing
- System panics to prevent potential data corruption
- Fencing startup reports preexisting split-brain
- Troubleshooting CP server
- Troubleshooting server-based fencing on the Arctera InfoScale products cluster nodes
- Issues during online migration of coordination points
- Troubleshooting notification
- Troubleshooting and recovery for global clusters
- Troubleshooting licensing
- Licensing error messages
- VCS message logging
- Troubleshooting and recovery for VCS
- Section VI. Troubleshooting SFDB
Recovering from a failed vxresize shrink operation
The vxresize command operates on both the file system and the underlying volume. For a shrink operation, the vxresize command calls the fsadm command to resize the file system and then calls the vxassist command to resize the underlying volume. In some cases, the file system shrink operation succeeds but the volume shrink operation fails. This situation may occur if you specify an invalid medianame operand to the vxresize command. A medianame operand may be invalid if the disk does not exist or if the disk is not in the specified disk group. The vxresize command passes the invalid parameter to the vxassist volume resize operation, which then fails. A message is displayed similar to the following:
VxVM vxassist ERROR V-5-1-18606 No disks match specification for Class: dm, Instance: vmr720-10_disk_14 VxVM vxresize ERROR V-5-1-4703 Problem running vxassist command for volume vol1, in diskgroup testdg
The operation results in a reduced file system size, but does not change the volume size. This behavior is expected; however, you need to correct the volume size to match the file system size.
Workaround:
Repeat the vxresize command with the required size but without any disk parameters. The file system is not resized again when the current file system size and new file system size are the same. The vxresize command then calls the vxassist command, which reduces the volume size. The file system size and the volume sizes are now the same.
The following example shows this workaround.
Example of recovery from a failed shrink operation
- Display the example configuration with the following commands:
# vxprint -uH | grep v1 v v1 fsgen ENABLED 11.00g - ACTIVE - - pl v1-01 v1 ENABLED 11.00g - ACTIVE - - sd hitachi_usp-vm0_0fc2-01 v1-01 ENABLED 7.96g 0.00 - - - sd hitachi_usp-vm0_0fc3-01 v1-01 ENABLED 3.03g 7.96g - - -
# df -g | grep v1 /dev/vx/dsk/testdg/v1 11.00 10.29 7% 5 1% /testfs1
The output shows that both the file system and the volume have the size of 11.00g.
- The below command shows the shrink operation with the invalid disk name:
# /etc/vx/bin/vxresize -g testdg v1 10g abcd1234 VxVM vxassist ERROR V-5-1-18606 No disks match specification for Class: dm, Instance: vmr720-10_disk_14 VxVM vxresize ERROR V-5-1-4703 Problem running vxassist command for volume v1, in diskgroup testdg
- Display the example configuration after the resize operation:
# vxprint -uH | grep v1 v v1 fsgen ENABLED 11.00g - ACTIVE - - pl v1-01 v1 ENABLED 11.00g - ACTIVE - - sd hitachi_usp-vm0_0fc2-01 v1-01 v1-01 ENABLED 7.96g 0.00 - - - sd hitachi_usp-vm0_0fc3-01 ENABLED 3.03g 7.96g - - -
# df -g | grep v1 /dev/vx/dsk/testdg/v1 10.00 9.36 7% 5 1% /testfs1
The output shows that the file system has the new size of 10.00g but the volume size is unchanged at 11.00g.
- Perform the resize operation again with no disk parameters:
# /etc/vx/bin/vxresize -g testdg v1 10g
- Display the example configuration after the resize operation:
# vxprint -uH | grep v1 v v1 fsgen ENABLED 10.00g - ACTIVE - - pl v1-01 v1 ENABLED 10.00g - ACTIVE - - sd hitachi_usp-vm0_0fc2-01 v1-01 ENABLED 7.96g 0.00 - - - sd hitachi_usp-vm0_0fc3-01 v1-01 ENABLED 2.03g 1.96g - - -
# df -g | grep v1 /dev/vx/dsk/testdg/v1 10.00 9.36 7% 5 1% /testfs1
The output shows that both the file system and the volume have the new size of 10.00g.