web-dev-qa-db-ja.com

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サーバーで2つの端末を使用する場合：

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ファイルロックがどのように機能すると予想されるのかを誤解していますか？サーバーアクセスとクライアントアクセスのどちらを処理する必要がありますか？または、それはクライアントアクセスと異なるクライアントアクセスだけのためですか？

nfslock
5
user1902689

flockはNFSでは機能しません。 （UNIXシステムであっても、これはありません。）

lockfとflockの1つの比較については、 flock vs Linuxのlockf を参照してください。

これが可能な解決策です シェルスクリプトの正しいロック？

6
roaima