Managing Serviceguard NFS for Linux, March 2009

NOTE: In versions A.02.00 and A.03.01 of the NFS toolkit, you can eliminate the above
limitations by enabling the File Lock Migration feature. (For more information, see the
“Overview of the NFS File Lock Migration Feature” section).
IPv6 addresses are not supported by NFS toolkit for NFS version 3 file lock migration feature.
Overview of the NFS File Lock Migration Feature
The following describes the File Lock Migration feature, which is part of the NFS toolkit with
version A.02.00 and A.03.01:
• Designate a unique holding directory as part of the NFS package located on a shared
filesystem. In other words, an empty directory is created on a shared filesystem that moves
between servers as part of the package. This holding directory is a user configurable
parameter ( NFS_FLM_HOLDING_DIR in hanfs.conf) and must be dedicated to hold the
Status Monitor(SM) entries only.
• The script, nfs.flm, periodically copies the Status Monitor entries from the/var/lib/
nfs/sm directory on SLES and /var/lib/nfs/statd/sm directory on Red Hat into the
package holding directory. The default for nfs.flm is to copy every five seconds. This
value can be changed by modifying the PROPAGATE_INTERVAL parameter in hanfs.conf.
• Since the holding directory resides on a shared filesystem, on failover, it transitions from
the primary node to the adoptive node defined by the NFS package. Once the holding
directory is made available on the adoptive node, the SM entries residing in the holding
directory are copied to the SM directory on the adoptive node (/var/lib/nfs/sm on SLES
and /var/lib/nfs/statd/sm on Red Hat). This sequence of actions sync the adoptive
server's SM directory with that of the primary server. Two NFS packages cannot run on the
same node when lock migration is used. See the limitations in the next section.
• After failover, the NFS package IP address is configured on the adoptive node, and
sm-notify on SLES and rpc.statd on Red Hat is restarted using package IP. Restarting
this daemon triggers a crash recovery notification event, whereby sm-notify/rpc.statd
sends crash notification messages to all clients listed in the SM directory.
• Any client that holds NFS file locks against files exported by the NFS package sends reclaim
requests to the adoptive node (where the exported filesystems currently reside) and reclaims
its locks.
• After sm-notify/rpc.statdsends 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 file in SM directory (/var/lib/nfs/sm
on SLES and /var/lib/nfs/statd/sm on Red Hat) of the NFS server into the holding
directory periodically. The entries that now appear in the SM directory on the adoptive node
following the package migration represent either a client that has reclaimed its locks or a
client that has established new locks after failover.
Limitations of the NFS File Lock Migration Feature
The following describes limitations of the NFS File Lock Migration feature:
• Multiple NFS packages are not supported on the same node
The file lock migration feature will not work for multiple NFS packages running on the same
node. So, if file lock migration feature is enabled then any node configured for NFS package
in a cluster, cannot be configured to run multiple NFS packages. This limitation is because
8 Serviceguard NFS for LINUX Introduction