在 NFS 上 flock(2) 与 fcntl(2)

Question

Perl 5.x 文档指出，它的 flock(..) 实现将使用以下本地调用之一，从 1 开始，如果不可用，则朝 3 工作：

1. 羊群(2)
2. fcntl(2)
3. 锁(3)

没关系。但是，您可能已经注意到他们的免责声明，即不应在 NFS 上使用 flock(2)。该文档建议使用 -Ud_flock 标志来强制 Perl 使用 flock(2)。flock(2) 的手册页（在 Redhat 上）陈述了关于 NFS 问题的类似免责声明。

我的问题是，为什么！？！？我似乎找不到深入的文章或解释为什么 flock(2) 在 NFS 上不安全。

我已经在 Redhat（使用 flock(2) 的地方）和 Solaris（使用 fcntl(2) 的地方）用 C 和 Perl 编写了几个测试脚本。我运行了 strace/truss 以确保 Perl 确实分别使用了 flock(2) 和 fcntl(2)。我无法复制任何没有兑现锁的问题！是什么赋予了？？

Answer 1

我很确定您正在考虑遗留问题。回想一下 Perl5 手册是在 1994 年发布的，它只是对 1991 年 Perl4 手册的编辑。在那些日子里，关于经常被称为噩梦文件系统的人可能会说“这不是熊跳舞得有多好”令人惊讶，但它根本不会跳舞”。

1991 年的 NFS2 正在慢慢地从 Sun 爬出到其他平台，并且相对粗糙。安全模型基本上不存在（客户端机器上的 root 可以读取 NFS 挂载的全部内容）并且锁定 - 通过 nfs.lockd - 是实验的这一方面。如果在两个不同的据称可互操作的实现之间完全存在，则期望群语义正常工作是愚蠢的。同轴电缆是当时占主导地位的以太网 PHY，许多网络用户从未对使用它感到不满（你的意思是你忘记把 50 终端电阻放在上面？）如果这能让你更好地掌握内部网的状态。

Larry Wall 和工作人员当时完全有理由对 NFS 锁的正确性做出悲观的假设，而这种防御性编程是未来的代码专家不愿意删除的，因为很难证明不存在缺陷删除旧代码，这些代码在与您从未听说过的遗留系统的互操作性中重新引入。

从那以后，NFS 有了很大的改进，并且 lockd 及时迁移到了 Linux 2.6 内核的一个特性。对于 2003+ 系统的集合，NFS 文件锁定可能是值得信赖的，特别是如果在您的应用程序中在它可能运行的许多平台上进行了很好的测试。

以上所有内容都是从记忆中抄袭的，可能会通过研究得到证实（例如http://nfs.sourceforge.net/），但证据 - 正如他们所说 - 在锁定中，如果你没有测试它，估计是坏了。

Answer 2

这已经过时了。NFS4 支持协议内部的锁定（不需要 lockd 守护进程或 RPC 回调机制）并且 Perl 的flock()方法工作正常 - 我们在生产中使用它。

非常旧的内核版本flock（系统调用）作为 NFS 上的无操作实现，并且没有正确支持字节范围锁定等其他内容。这就是歇斯底里的来源。

Answer 3

Lennart Poettering 最近对 Linux 文件系统锁定行为进行了一些深入研究，这并没有为 NFS 锁定描绘出一幅特别美好的图景（尤其是他在帖子底部链接到的后续内容）。

http://0pointer.net/blog/projects/locking.html