Serviceguard NFS Toolkit A.11.11.05 and A.11.23.04 Release Notes
Serviceguard NFS Toolkit A.11.11.05 and A.11.23.04 Release Notes
Features and Fixes in Recent Releases
8
Once the holding directory is on the adoptive node, the SM entries residing in the holding
directory are copied to the /var/statmon/sm directory on the adoptive node. This
populates the new server’s SM directory with the entries from the primary server.
• After failover, the HA/NFS package IP address is configured on the adoptive node, and
rpc.statd and rpc.lockd are killed and restarted. This killing and restarting of the
daemons triggers a crash recovery notification event, whereby rpc.statd sends crash
notification messages to all the clients listed in the /var/statmon/sm directory.
These crash recovery notification messages contain the relocatable hostname of the
HA/NFS package that was previously running on the primary node and is currently
running on the adoptive node.
• Any client that holds NFS file locks against files residing in the HA/NFS package
(transitioned between servers) sends reclaim requests to the adoptive node (where the
exported filesystems currently reside) and reclaims its locks.
• After rpc.statd sends the crash recovery notification messages, the SM entries in the
package holding directory are removed, and the nfs.flm script is started on the adoptive
node. The script once again copies each /var/statmon/sm file on the HA/NFS server into
the holding directory, every five seconds. Each file residing in the /var/statmon/sm
directory on the adoptive node following the package migration represents a client that
either reclaimed its locks after failover or has established new locks after failover.
NOTE Serviceguard NFS cannot be used for an NFS diskless cluster server.