This page describes caveats when using NFS locking in a Linux-cluster environment.
In simple terms this is what works in Linux-cluster environment with NFS and locks:
- If you want to use NFS failover then NFS locks are not supported.
- If you want to use NFS locks then NFS failover are not supported.
- Use nfsv4 on server/client when at all possible.
Believed to work:
- NFS lock failover when using a single-node file system such as ext3 or xfs where an IP is moved with a service in an attempt to provide "transparent" failover to a client or set of clients.
- Requires several configuration steps in order to set up correctly - Documentation TBD
- Multiple NFS servers serving the same gfs or gfs2 file system behave as expected so long as failover is not required. This means that applications running on NFS clients which rely on POSIX locks to protect their data will work across NFS when GFS is used as the backing store, even if clients are not accessing the same NFS server. (See Known Issues)
What does not work:
- Multiple NFS servers serving the same gfs or gfs2 file system in a server-side failover environment where a server recovers an IP address in an attempt to provide "transparent" failover to a client or set of clients. In order to do this, gfs and gfs2 would need the ability to manage NLM reclaim grace periods cluster-wide.
- Multiple NFS servers serving the same GFS file system in a client-side failover environment whereby the client, upon receipt of errors, redirects subsequent NFS traffic to a new NFS server. There is no mechanism for NFS to migrate a client's lock from one GFS node to another.
- Pursuant to bugzilla #470074, overlapping POSIX range locks taken from different NFS servers serving the same GFS file system does not currently work.
- Posix issue with GFS1/2 and locks. nfsv4 seems to mitigate this issue bugzilla #502977.