web-dev-qa-db-ja.com

NFS：リモートロックとは何ですか？それは必要ですか？

シリアルポートデータを収集し、NFSマウントのログファイルに入力する、ややミニマルなシステムを構築しています。

システムをいくらか削減するために、RPCの使用法がわからなかったため、RPCを無効にすることにしました。その結果、次の警告が表示されました。

mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

RPCがNFSに関与しているのは当然のことなので、次のステップは警告を削除することです。 RPCを再度有効にするか、-o nolock推奨通り。

では、問題は、リモートロックは正確には何をするのでしょうか。この特定のケースでは、NFSマウントは問題のマシンによってのみ書き込まれ、複数のプロセスが同じファイルに書き込むなどの競合の可能性はありません。 （ただし、いくつかのプロセスがそれぞれ独自のログファイルに書き込みます）

Debian Buster、カーネル4.19の実行

編集：試しました-o nolock、そして物事はうまく機能しているように見えるので、一見すると、悪影響はありません。

linuxnfsmountrpc
4
Jarmund

答えは、rpc.statdの古き良きmanページにあります。

ファイルロックは、永続的なファイルシステムの状態の一部ではありません。したがって、ホストが再起動すると、ロック状態は失われます。

ネットワークファイルシステムは、リモートホストが再起動したためにロック状態が失われたことも検出する必要があります。 NFSクライアントが再起動した後、NFSサーバーは、そのクライアントで実行されていたアプリケーションによって保持されているすべてのファイルロックを解放する必要があります。サーバーの再起動後、クライアントはそのクライアントで実行されているアプリケーションによって保持されているファイルロックをサーバーに通知する必要があります。

NFSバージョン2 [RFC1094]およびNFSバージョン3 [RFC1813]の場合、ネットワークステータスモニタープロトコル（略してNSM）を使用して、NFSピアに再起動を通知します。 Linuxでは、2つの個別のユーザー空間コンポーネントがNSMサービスを構成します。

rpc.statd

他のホストからの再起動通知をリッスンし、ローカルシステムの再起動時に通知されるホストのリストを管理するデーモン

sm-notify

ローカルシステムの再起動後にNFSピアに通知するヘルパープログラム

つまり、基本的に、NFSサーバーで実行されているrpc.statdは、他のNFSクライアントで実行されているプロセスが、クライアントマシンからロックしたファイルにアクセスできないようにします。クライアントが1つしかない限り、ローカルロックは問題ありません。しかし、通常、NFSは共有にすべてをかけています。

3
wazoox