NFSファイルロックが機能しません。私が誤解しているのですか？

2024-5-22 • tag-icon

複雑なファイル共有設定を計画しており、ファイルロックが壊れないようにしたいと思います。（同じデータに対してrdma（InfiniBandファイル共有）とvirtfs（kvm仮想マシンパススルーファイル共有）を介してバインドマウント、nfs、nfsを使用したいと思います。）

ちょうど完全性チェックを開始し、単一のnfsクライアントを使用してnfsサーバーをテストしました。どちらのシステムも、nfs-utils 1.3.2-6、カーネル4.1.6-1に最新のArchをインストールします。

予期しない結果を見ました。 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にはcontentというスクリプトがあります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ファイルロックがどのように機能するかを誤解していますか？サーバーアクセスとクライアントアクセスを処理すると予想していますか？それとも単にクライアントアクセス用ですか、それとも別のクライアントアクセス用ですか？

答え1

flockNFSでは機能しません。（UNIXシステムでも絶対にそうではありません。）

バラよりLinuxのクラスタリングとlockflockf比較してflock。

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

答え1

関連情報