Linux中flock在分布式文件系统上能否跨节点互斥，取决于文件系统是否原生支持强一致性锁：CephFS（v14+内核客户端或fuse v16+）和启用locking模块的GlusterFS可行；NFSv3/v4.0、Lustre、BeeGFS、GPFS、CIFS均不适用；必须所有进程主动调用flock且锁文件置于共享路径。

Linux 中的 flock 是建议性锁（advisory lock），它不依赖文件系统类型，而是由内核在 VFS 层实现，只要底层文件系统支持 inode 级锁语义（绝大多数主流本地文件系统如 ext4、xfs 都支持），flock 就能正常工作。但关键点在于：分布式文件系统是否真正支持跨节点协同的、一致的 flock 行为——这决定了它能否用于避免集群多写冲突。

简单说：不是“挂载时开启 flock”，而是“选对支持一致锁语义的分布式文件系统 + 正确配置 + 应用层配合使用”。

以下是实际可行的路径：

✅ 1. 优先选择原生支持强一致性锁的分布式文件系统

• CephFS（推荐）

  • Ceph 从 v14（Nautilus）起，通过 ceph-fuse 或内核客户端（ceph.ko）挂载的 CephFS，默认支持 flock（基于 MDS 的元数据协调）。
  • 关键要求：
    • 使用 kernel client（mount -t ceph） 或 ceph-fuse ≥ v16（Octopus）；旧版 fuse 可能降级为本地模拟锁，不跨节点生效。
    • 确保 MDS 开启 enable_locks = true（默认开启）；无需额外挂载参数。
  • 挂载示例（kernel client）：

    mount -t ceph node1:6789,node2:6789:/ /mnt/ceph -o name=admin,secretfile=/etc/ceph/admin.secret

    → 此后 flock -x /mnt/ceph/shared.log 在任意节点上均具备跨节点互斥效果。

• GlusterFS（需启用 locking 模块）

  • Gluster 默认不强制同步锁状态，必须显式启用 cluster.locking 和 features.locks：

    gluster volume set volname cluster.locking on
    gluster volume set volname features.locks on

  • 客户端挂载时无需特殊选项，但必须使用 glusterfs 原生客户端（非 NFS 导出）：

    mount -t glusterfs server1:/volname /mnt/gluster

  • 注意：Gluster 的 flock 实现是基于 inodelk 和 entrylk 的协作机制，实测在多数场景下可保证排他性，但高并发小文件争抢时偶有延迟，建议搭配 -n（非阻塞）使用。

⚠️ 2. 明确不适用或需规避的方案

• NFSv3/NFSv4.0：

  • NFSv3 完全不传递 flock；NFSv4.0 虽支持 fcntl 锁，但 flock 在多数客户端（如 Linux kernel NFS）中被降级为本地锁，跨节点无效。
  • ❌ 不可用于防多写冲突。

• Lustre、BeeGFS、GPFS（IBM Spectrum Scale）：

  • 这些面向 HPC 的并行文件系统通常不兼容 POSIX flock 语义，它们用自有锁机制（如 Lustre 的 DLM），flock() 调用可能直接返回 ENOSYS 或静默失败。
  • 如需锁控制，必须使用其 SDK（如 Lustre 的 llapi_file_create() + llapi_lock_acquire()）。

• Samba/CIFS 挂载：

  • Windows SMB 协议层锁与 POSIX flock 无映射关系，Linux 上 flock 对 CIFS 挂载点完全无效。

✅ 3. 必须配合的应用层实践（否则锁形同虚设）

• flock 是建议性锁，所有参与进程必须主动调用才能生效：

  • 写入脚本必须包裹 flock -x /shared/path/lockfile -c 'your_command'；
  • 不能只靠“某人加了锁，别人就自动被拦住”——没调 flock 的进程照常写。

• 锁文件应放在共享存储根路径下（如 /mnt/ceph/.deploy.lock），而非本地 /tmp。

• 推荐加 -n（非阻塞）+ 超时反馈，避免任务堆积：

  if flock -n /mnt/ceph/.deploy.lock; then
      ./deploy.sh
      rm -f /mnt/ceph/.deploy.lock  # 实际无需删，flock 自动释放
  else
      echo "Skip: another node is deploying" >&2
  fi

✅ 4. 替代方案（当 flock 不可靠时）

若所用分布式文件系统锁支持弱（如某些 NFS-on-cloud 场景），应转向：

• 基于 Redis 的分布式锁（如 redlock）；
• etcd/ZooKeeper 的临时有序节点（ephemeral znode）；
• 数据库行锁（如 SELECT ... FOR UPDATE on a shared control table）；
• 专用协调服务（Consul Session + KV）。

这些方案不依赖文件系统语义，可靠性更高，但需引入外部依赖。

不复杂但容易忽略。