 | ||
| Mount agent notes | ||
|---|---|---|
| Prev | Storage agents | Next |
The Mount agent has the following notes:
The high availability fire drill detects discrepancies between the VCS configuration and the underlying infrastructure on a node; discrepancies that might prevent a service group from going online on a specific node. For Mount resources, the high availability drill performs the following, it:
For more information about using the high availability fire drill see the Veritas Cluster Server User's Guide.
If the mount option in the mount table output has the option mntlock="key", then it is locked with the key "key". To verify if mount locking is in use and has the value of "key", run the mount command and review its output.
If the VxFS file system has mntlock="key" in its mount options, then unmounting the file system fails.
You can unlock the file system with the fsadm command and then unmount it. To unlock a locked mount, run the following command where "key" is the lock identifier and mount_point_name is the file system mount point.
# /opt/VRTS/bin/fsadm -o mntunlock="key" mount_point_name
To unmount a file system mounted with locking, run the vxumount command with the option mntunlock="key", for example:
# /opt/VRTS/bin/vxumount -o mntunlock="key" mount_point_name
When a file system has heavy I/O, the umount command can take several minutes to respond. However, the umount command temporarily deletes the mount point from mount command output while processing. Per IBM, this is the expected and supported behavior on AIX. The umount command's processing later puts the mount point back if the mount point is found busy. Meanwhile, the default OfflineTimeout value of the Mount agent can get exceeded, which in turn invokes the Clean agent function. The Clean function can find the mount point's entry absent from the mount command output and exit with success.
The unmounting, however, may not have happened yet. If unmounting did not occur, offlining resources below the Mount resource (for example the LVMVG or DiskGroup resources) can fail.
The Mount resource's Offline agent function then proceeds to unmount the mount point. After several attempts, the Clean scripts that clean the resources below the Mount resource succeed and the group goes offline.
See the VCS User's Guide for more information about the OfflineTimeout attribute.
In this /etc/filesystems entry for a VxFS file system created on a VxVM volume, /mount_point is the mount point for the file system, /dev/vx/dsk/Diskgroup_name/Volume_name is the block device on which the file system is created, and vxfs is the file system type.
dev = /dev/vx/dsk/Diskgroup_name/Volume_name
In this /etc/filesystems entry for a JFS file system created on an LVM logical volume, /mount_point2 is the mount point for the file system, /dev/LVMlogical_volume is the block device on which the file system is created, /dev/LVMlogical_volumelog is the log device for the file system automatically created by the crfs command, and jfs is the file system type.
log = /dev/LVMlogical_volumelog
Use the crfs and mkfs commands to create file systems. VCS supports the following configurations for the Mount agent:
If you want to use the Mount resource to monitor the ZFS file system, perform the following steps.
Create the tank storage pool and file system on the disk device c1t0d0 for example.
Create the home file system in tank.
Set the value of the MountPoint attribute to legacy.
# zfs set mountpoint=legacy tank/home
Set the Mount agent's attributes. The following is an example of this configuration's main.cf file.