Overview of the NFS File Lock Migration Feature

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.