NFS网络锁管理器（NLM）

最初构思和建立NFS时是想用来管理对单个数据存储设备的分布式访问，使用独立的程序进行锁仲裁。因为文件系统和它的锁定方法是独立实现的，最初的NFS开发者感到他们正在提供一种通用的网络锁仲裁，或许可以用在所有的网络文件系统中。然而，可惜的是，直到网络锁管理器（NLM）变得非常有名时，它仍然只被广泛地用作NFS v3服务器和NFS v3客户端的锁仲裁方法。NFS v4协议不是使用的独立的守护进程或协议进行锁定，但是许多概念仍然是一样的，因此我们将通过讨论NFS v3 NLM来介绍NFS锁定。

NLM由两个守护进程组成：statd和lockd。这两个守护进程同时都要在NFS服务器和NFS客户端上运行，以便每个人都清楚什么被锁了，以及是哪个程序或进程锁定的。运行在客户端和服务器上的statd守护进程持有一份持有锁的主机清单（在NFS服务器上，主机指NFS客户端，在NFS客户端上，主机指NFS服务器[5]），NFS客户端上的lockd守护进程负责与NFS服务器上lockd守护进程协商申请一个锁请求。
让我们更进一步检查一下这两个守护进程。

statd

在集群中，statd也叫做rpc.statd，它运行在每个集群节点上，在NFS服务器上保留一个锁，以防节点崩溃，如果真的发生了这种事情，当集群节点重启恢复正常后，集群节点上的rpc.statd程序将会通知NFS服务器，NFS客户端上的statd知道它会这么做，因为在集群节点上的进程首次尝试锁定NFS服务器上的文件时，它在本地写下了每个NFS服务器的名字，当NFS服务器接收到这个通知后，它会认为所有来自集群节点（或NFS客户端）的持有锁的进程不再运行，它会释放掉这些锁。

注意：statd或rpc.statd有时被作为一个网络状态监视器（NSM）。

lockd

Linux内核知道Posix fcntl锁请求的文件或文件的一部分存储在一个NFS服务器上，因为文件存储在一个NFS挂载类型的文件系统上，如果Linux机器是一个NFS客户端，内核知道它需要将锁请求传递到本地运行的lockd守护进程[6]，然后，NFS客户端上的lockd守护进程联系NFS服务器上的lockd守护进程，并请求锁，然后，NFS服务器上的lockd守护进程代表NFS客户端向它的内核申请一个锁。

如果不止一次相同的程序或进程要相同的锁[7]，那么每次都会获得一个锁，内核不认为这样违背了锁的原则，在lockd成为内核的一部分之前，单个进程不止一次获得相同的锁，即lockd守护进程必须记录NFS客户端产生的锁请求，在向内核申请锁之前，否决所有的冲突，lockd可能会不知不觉地为两个不同的NFS客户端请求、获得同一个锁两次。