Jar*_*und 6 linux nfs mount rpc
我正在构建一个有点简约的系统，该系统收集串行端口数据并将其推送到 NFS 挂载上的日志文件中。
为了稍微减少系统，我决定禁用 RPC，因为我看不到它的用途，这导致了以下警告：
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
毫不奇怪，RPC 涉及到 NFS，真的，所以我的下一步是删除警告。我可以选择重新启用 RPC，或者-o nolock按照建议使用。
那么问题来了，远程锁定究竟有什么作用呢？在这种特殊情况下，NFS 挂载仅由相关机器写入，并且不存在冲突的可能性，例如多个进程写入同一文件。（虽然，有几个进程写入每个自己的日志文件）
运行 debian buster，内核 4.19
编辑：我试过-o nolock，事情似乎工作正常，所以乍一看，没有不利影响。
答案在于 rpc.statd 的好老手册页：
文件锁不是持久文件系统状态的一部分。因此，当主机重新启动时，锁定状态将丢失。
网络文件系统还必须检测锁定状态何时因远程主机重新启动而丢失。NFS 客户端重新启动后，NFS 服务器必须释放在该客户端上运行的应用程序持有的所有文件锁定。服务器重新启动后，客户端必须提醒服务器该客户端上运行的应用程序持有的文件锁。
对于 NFS 版本 2 [RFC1094] 和 NFS 版本 3 [RFC1813]，网络状态监视器协议（或简称 NSM）用于通知 NFS 对等端重新启动。在 Linux 上，两个独立的用户空间组件构成 NSM 服务：
rpc.statd
监听来自其他主机的重启通知的守护进程，并管理本地系统重启时要通知的主机列表
sm-通知
在本地系统重新启动后通知 NFS 对等方的帮助程序
因此，基本上，运行在 NFS 服务器上的 rpc.statd 会阻止在其他 NFS 客户端上运行的进程访问您从客户端计算机锁定的文件。只要只有一个客户端，本地锁就可以了。但通常 NFS 都是关于共享的。