我正在构建一个有点简约的系统，收集串行端口数据并将其推送到 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，一切似乎都运行良好，所以乍一看，没有什么不良影响。
答案1
答案就在 rpc.statd 的手册页中：
文件锁不是持久文件系统状态的一部分。因此，当主机重启时，锁定状态会丢失。
网络文件系统还必须检测远程主机重新启动导致锁定状态丢失的情况。NFS 客户端重新启动后，NFS 服务器必须释放该客户端上运行的应用程序所持有的所有文件锁定。服务器重新启动后，客户端必须提醒服务器该客户端上运行的应用程序所持有的文件锁定。
对于 NFS 版本 2 [RFC1094] 和 NFS 版本 3 [RFC1813]，网络状态监视器协议（简称 NSM）用于通知 NFS 对等方重新启动。在 Linux 上，两个独立的用户空间组件构成了 NSM 服务：
rpc.statd
监听其他主机重启通知的守护进程，并管理本地系统重启时要通知的主机列表
短信通知
本地系统重启后通知 NFS 对等体的辅助程序
因此，基本上，在 NFS 服务器上运行的 rpc.statd 会阻止在其他 NFS 客户端访问您从客户端计算机锁定的文件。只要只有一个客户端，本地锁定就可以了。但通常 NFS 都是关于分享。