标签: 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}
Run Code Online (Sandbox Code Playgroud)

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

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

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

nfs lock concurrency ln gfs

6
推荐指数
1
解决办法
1544
查看次数

标签 统计

concurrency ×1

gfs ×1

ln ×1

lock ×1

nfs ×1