![`ln` 在 NFS 上是原子的且可靠的吗?在此用例中,NFS 能否取代 GFS?](https://linux22.com/image/53406/%60ln%60%20%E5%9C%A8%20NFS%20%E4%B8%8A%E6%98%AF%E5%8E%9F%E5%AD%90%E7%9A%84%E4%B8%94%E5%8F%AF%E9%9D%A0%E7%9A%84%E5%90%97%EF%BC%9F%E5%9C%A8%E6%AD%A4%E7%94%A8%E4%BE%8B%E4%B8%AD%EF%BC%8CNFS%20%E8%83%BD%E5%90%A6%E5%8F%96%E4%BB%A3%20GFS%EF%BC%9F.png)
我有一个包含一堆服务器的集群,其中包含一个共享磁盘,其中包含所有节点同时访问的 GFS 全局文件系统。
集群中的每个节点都运行相同的程序(shell脚本是主要核心)。系统处理出现在几个输入目录中的文件,其工作原理如下:
- 程序循环遍历输入目录。
- 对于找到的每个文件,检查是否存在“锁定文件”,如果锁定文件存在,则跳到下一个文件。
- 如果未找到锁定文件,则创建锁定文件。如果锁定文件创建失败(竞赛失败),则跳到下一个文件
- 如果“我们”拥有锁,则处理该文件并在完成后将其移开。
这一切都工作得很好,但我想知道是否有更便宜(不太复杂)的解决方案也可以工作。我想也许是 NFS 或 SMB。
我使用GFS有两个原因:
- 每个文件仅存储在一个位置(当然是在冗余的底层硬件上)
- 文件锁定工作可靠
我这样创建锁文件:
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 上的工作方式一样可靠吗?
答案1
link()
NFS 客户端上的系统调用应直接映射到 NFS操作LINK
,服务器应使用其link()
系统调用来实现该操作。因此,只要link()
在服务器上是原子的,它在客户端上也将是原子的。