Error Message

When attempting to deport the Veritas Volume Manager (VxVM) diskgroup, it failed with the below error message:

vxvm:vxconfigd: V-5-1-16251 Disk group deport of failed with error 70 - Volume or plex device is open or attached
 

During the mount operation of a dirty VxFS file system, the VxVM device encounters an open count leak.
 

Sample VxFS mount messages

# mount -t vxfs /dev/vx/dsk// /
log replay in progress
replay complete - marking super-block as CLEAN

Note: Only when a VxFS log replay is performed is the issue encountered, the mount operation leads to an open count leak.

Consequently, after the VxFS file system is unmounted, the VxVM deport operation of the VxVM diskgroup fails with an open device failure.

The issue is related to a code regression for a single code change made available with the InfoScale 7.4.2 U6 patch release for Linux.
 

Note: Standard shutdown/reboot operations may hang due to the VxFS lock which is why a hard system reset/panic of the affected node(s) is necessary.

This can be done by executing "echo c > /proc/sysrq-trigger".

# echo c > /proc/sysrq-trigger

Veritas has recently released the following InfoScale 7.4.2.x public patch bundles for RHEL7 + RHEL8.

Public patches

Table 1.0

For InfoScale 7.4.2.x

Note: The Cumulative patch bundle must be installed first, followed by the Component patch bundle.

The component patch includes a subset of public patches for VRTSodm, VRTSvxfs and VRTSvxvm.
The public component patch bundles now supersede the below private hotfixes:


Private hotfixes

Table 2.0

For InfoScale 7.4.2.x

Please note that Veritas Technologies LLC reserves the right to remove any fix from the targeted release if it does not pass quality assurance tests.  Veritas’ plans are subject to change and any action taken by you based on the above information or your reliance upon the above information is made at your own risk.

Workaround:

Prior to mounting the suspect file system.

1.] The file system can be manually checked using the fsck -m option prior to mounting.

If the fsck -m option returns the sanity check as OK, the mount operation can continue as normal.

Example:

# /opt/VRTS/bin/fsck -t vxfs -m /dev/vx/rdsk//
UX:vxfs fsck: INFO: V-3-20915: sanity check: /dev/vx/rdsk// OK

# echo $?
0

fsck option

-m        Reports whether the file system was marked clean and  return an  exit  code. 
            A zero indicates the file system is clean, a 32 indicates that  the  file  system  needs  checking.  
            This option does not validate the file system.

            Exit codes are 33 (mounted) 32 (dirty) and 0 (clean)

If the VxFS file system is dirty, a simple fsck operation can be performed against the impacted file system.

# /opt/VRTS/bin/fsck -t vxfs /dev/vx/rdsk//

Following an upgrade to InfoScale 7.4.2 Update 6 (VRTSvxfs-7.4.2.4500) on Linux, users may be unable to deport their diskgroups. When file systems are not unmounted cleanly on Node A/Cluster A, the services will continue to failover as designed for Node B/Cluster B, in case of hardware or node failures.

However, when failing back the services to the original Node A/Cluster A, due to open count leak in the VxFS layer. The VxVM diskgroup may fail to be deported. The issue is applicable to all types of configurations, such as hardware replication, private and cvm diskgroups. In cvm/cfs environments this issue will not be hit until there is only one node left in the cluster with the cfs filesystem(s) mounted and this node is also shutdown.

If other possible reasons for the Diskgroup deport to fail with this error have been ruled out, then the only way to restore normal application functionality is via a hard system reset/panic of the impacted node(s). No issues occur when file systems are cleanly unmounted during failover/failback operations.

JIRA: STESC-8273