`ln` 在 NFS 上是原子的且可靠的吗？在这个用例中 NFS 可以取代 GFS 吗？

Question

我有一个集群，其中包含一堆服务器，共享磁盘包含所有节点同时访问的 GFS 全局文件系统。

集群中的每个节点都运行相同的程序（一个 shell 脚本是主要的核心）。系统处理出现在几个输入目录中的文件，它的工作方式如下：

• 程序循环遍历输入目录。
• 对于找到的每个文件，检查是否存在“锁定文件”，如果存在锁定文件，则跳到下一个文件。
• 如果没有找到锁定文件，则创建锁定文件。如果锁文件创建失败（比赛失败），跳到下一个文件
• 如果“我们”拥有锁，则处理文件并在完成后将其移开。

这一切都很好，但我想知道是否有更便宜（不太复杂）的解决方案也可以使用。我可能在考虑 NFS 或 SMB。

我使用 GFS 的原因有两个：

1. 每个文件只存储在一个地方（当然是在冗余的底层硬件上）
2. 文件锁定工作可靠

我像这样创建锁文件：

date '+%s:'${unid} > ${currlock}.${unid}
ln ${currlock}.${unid} ${currlock}
lockrc=$?
rm -f ${currlock}.${unid}

其中$unid是唯一的会话标识符，$currlock是/gfs/tmp/lock.${file_to_process}

的美妙之ln处在于它是原子的，因此除了同时尝试同一件事的人之外，其他所有人都失败了。

所以，我想我要问的是：NFS 能满足我的需求吗？ln在 NFS 和 GFS 上是否以相同的方式可靠地工作？

Answer 1

NFS 客户端上的系统link()调用应直接映射到 NFSLINK操作，服务器应使用其link()系统调用来实现该操作。因此，只要link()在服务器上是原子的，它在客户端上也将是原子的。