NFSクライアントアクセス時のタイムラグについて

質問

UNIX環境下での一般的なNFSクライアント-サーバ環境での質問です
（特定ベンダーのプロダクトに焦点を当てたものではありません）。

NFS Server(A)上のファイルシステムに保存してあるファイル(1)に対して
NFS Client(B)とNFS Client(C)がアクセスしています。
NFS Client(B)とNFS Client(C)はネットワーク、ファイルアクセスに対する
特権等全て同等のClientです。

NFS Client(B)がファイル(1)に対して"chmod"でファイルの属性を変更した
と同時にNFS Client(C)が"ls -l"等でファイルの状態を確認していますが
NFS Client(B)がファイル(1)の属性を変更してから、
NFS Client(C)からファイル(1)の属性が変更されていることを確認できる
までに（"ls -l"実行結果が見えるまでに）0.3秒程のタイムラグが
発生します。

上記の事象が発生する原因として考えられるものは
以下の点以外に何が考えられるでしょうか？
- ネットワーク環境による遅延
- NFS Client(C)の持つキャッシュによる遅延

また、この遅延はNFSのProtocolの仕様（ファイルロック制御等）に
よるものではなくNFSを使用している環境に依存しているもの
という認識で間違いないでしょうか？

ご意見、、ご指摘、アドバイス等ありましたらよろしくお願い致します。

回答No.2

a-saitoh · ベストアンサー

いったい何を問題にしているのか理解に苦しみますがとりあえず答えてみます．

ファイルの内容と保護モードのキャッシュのメカニズムは異なります．クライアント側のマウントオプションで，モードキャッシュ時間が制御できたように記憶しています．

ネットワークによる遅延も，コンマ３秒だと十分にその中のある割合を占めているでしょうね．クライアントAが保護モードを変える操作をしてそれが実際にサーバに伝わるまでの遅延もあるでしょう．

あと，NFSは明示的なロック機能を使う場合は除いてロックしないと思いますよ．

お礼

a-saitohさん

ご回答ありがとうございます。
最初の質問で意図している部分は、
同じファイルにアクセスしているのに、見える状態が違うことの
要因として可能性のあるものを上げたいということです。

NFS Clientの持つLocalキャッシュとファイル制御機能、
NFS Server側のファイルアクセス機構等も見え方に遅延の発生する
要因の一つだと考えました。
しかしNFSもv4じゃないと排他制御が確実に機能しないので
（本環境はNFSv2 or v3なので）、ロック制御の観点も遅延と
直接関係があるといえるか根拠に欠ける部分があり質問させて頂いている経緯もあります。

こちらでも限られた範囲のみですが確認できることはテストを実施していますが、
今のところNFS ClientのキャッシュをOFFにした状態で
最初の質問の通りにアクセスしてみましたが0.1秒程度に変わりました。

回答No.3

a-saitoh

「同じファイルにアクセスしているのに、見える状態が違う」
のは分散システムの本質ですから，それが嫌ならNFSはやめて，
サーバ1台+シンクライアント　という構成にするしかないです．

回答No.1

qaz_qwerty_me

ＮＦＳは、サーバーのファイルをクライアントに存在するファイルと同様に利用できるようにさせる機能ですから、
１．Client(B)がファイル(1) -> NSF Server へ
２．NSF Server上のNFSの処理
３．NSF Server -> Client(C)がファイル(1)へ
という順番で変更内容が伝わると思います。

３０秒のタイムラグは、ファイルロック制御等＋ネットワーク環境による遅延？と推測できますが、定量的に論ずるのはネットワークやホストの性能を変えて測定しないと無理と思います。

お礼

qaz_qwerty_meさん

ご回答ありがとうございます。

そうですね、実際に値を出して考えるのは難しいというのは理解できます。

ちょっと質問の趣旨が変わってしまいますが、ファイルの属性を変更する
（chmodする）だけでもファイルのロック制御が働くという認識は
合っているのでしょうか？
実際にchmodして属性変更し終わるのは、体感的にほんの一瞬なのですが
その処理だけに特化して遅延という事象が考えられるか？というところを
考えています。