NFS 文件鎖定不起作用，我是不是誤會了？

我計劃進行複雜的文件共享設置，並希望確保不會破壞文件鎖定。（想在相同的數據上使用綁定掛載、nfs、nfs over rdma（InfiniBand 文件共享）和 virtfs（kvm 虛擬機直通文件共享）。）

我剛開始進行健全性檢查，只是使用單個 nfs 客戶端測試 nfs 伺服器。兩個系統上的最新 Arch，nfs-utils 1.3.2-6，核心 4.1.6-1。

我看到了意想不到的結果。在 nfs 伺服器上：

server exports with: /test 192.168.0.0/16(rw,sync,no_subtree_check,
  no_root_squash)
client mount shows: 192.168.1.2:/test on /test type nfs4 (rw,noatime,vers=4.2,
  rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,
  retrans=2,sec=sys,clientaddr=192.168.1.3,local_lock=none,addr=192.168.1.2)

在 /test 中，我有一個以lockFile內容命名的腳本：

#!/bin/bash
filename="lockedFile"
exec 200>$filename
flock -n 200 || exit 1
pid=$$
while true; do
  echo $pid 1>&200
done

如果我在 nfs 伺服器上使用兩個終端：

1: ./lockFile
2: ./lockFile

然後，終端 1 用它的 pid 快速填充一個文件，終端 2 立即退出。一切如預期。

但是，如果我在 nfs 伺服器和客戶端上分別執行一個終端：

server: ./lockFile
client: ./lockFile

兩人歡快地奔跑，非常出乎意料。

在此配置中，我的 nfs 伺服器執行為sync，這意味著伺服器僅在實際寫入數據時才表示已寫入數據。我的 nfs 客戶端執行為async，這意味著客戶端僅在文件關閉時傳輸寫入。

我可以看到客戶端正在執行，async可能在它實際傳輸寫入之前沒有獲得鎖，所以我對此進行了測試，將客戶端更改為sync.

client mount now shows: 192.168.1.2:/test on /test type nfs4 (rw,noatime,sync,
  vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,
  retrans=2,sec=sys,clientaddr=192.168.1.3,local_lock=none,addr=192.168.1.2)

仍然lockFile愉快地在兩台機器上執行。

我是否誤解了 NFS 文件鎖定的預期工作方式？是否期望處理伺服器訪問與客戶端訪問？或者，它只是用於客戶端訪問還是不同的客戶端訪問？

flock不適用於 NFS。（它從來沒有，即使在 UNIX 系統上也是如此。）

有關 和的比較，請參見Linux 上的flock vs lockf。lockf``flock

這是一個可能的解決方案正確鎖定 shell 腳本？

引用自：https://unix.stackexchange.com/questions/229675