☰

`ln` 在 NFS 上是原子的且可靠的吗？在此用例中，NFS 能否取代 GFS？

tag-icon • tag-icon nfs lock ln concurrency gfs
`ln` 在 NFS 上是原子的且可靠的吗？在此用例中，NFS 能否取代 GFS？

我有一个包含一堆服务器的集群，其中包含一个共享磁盘，其中包含所有节点同时访问的 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 能满足我的需求吗？lnNFS 上的工作方式与 GFS 上的工作方式一样可靠吗？

答案1

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

相关内容