web-dev-qa-db-ja.com

新しく作成されたファイルをチェックするときにNFSキャッシュを強制的に更新する方法

Linux NFS共有マウントでファイルが作成される場合、クライアントはLinuxまたはMacマシンです。ファイルの存在または不在が次に行うべきことの鍵となりますが、チェックが常に正しい結果を返すとは限りません。

例えば私はこれをPerlでやっています、これはまだうまくいきません、特にmacマシンで

write_key_file();  # write a file that must be checked before proceeding

次のチェックは、ファイルが存在する場合に常にtrueを返すとは限りません

問題-PerlのこのコマンドはNFSシステムで正しいステータスを返しませんでした：

if( -e $file){}

機能しなかった耳にしたソリューション：

 sleep(5);   # wait 5 seconds
 system("ls -ltr"); # force to cache?
 if(-e $file){}

このようにすべてのファイルをチェックするつもりはありませんが、適切なファイルステータスを取得することが重要ないくつかの重要な場所があります。

特定のディレクトリの特定のファイルでNFSキャッシュを強制的に更新するより良い方法はありますか？ありがとう。

これがXY問題であるかどうかはわかりませんが、すべてが解決策になる可能性のあるいくつかの最も弱い点があります。

A-NFSクライアント設定

この段階で解決策があれば、すばらしいでしょう。

B-exit_codeまたは書き込み関数の戻りコード

$exit_code = write_key_file();

すべての書き込みがコードブロックのスコープ内にあるわけではありません。これは問題の一部しか解決しません。

C-ファイルチェックのために特定のファイルまたはディレクトリのNFSキャッシュを無効にする

これが可能かどうか、またその方法を確認する必要がありますか？いいえの場合、その理由は？

そして、私はすべての可能な解決策を受け入れ、解決策や他の可能性はありません。

linuxperlnfs
12
Gang

このソリューションはカテゴリBに属します：exit_codeまたは書き込み関数の戻りコード

...open()とfopen()のみが、読み取りと書き込みのために特定のファイルへの一貫したハンドルを取得することを保証する必要があります。 statおよび友達は、新しい属性を取得する必要はありません。したがって、close-to-openキャッシュコヒーレンスのために、open()とfopen()のみが考慮されます新しい属性をサーバーからすぐにフェッチする必要がある「オープンイベント」[1]。

次のソリューションはカテゴリAに属します：NFSクライアント設定
すなわちキャッシュされたファイル/ディレクトリエントリがクライアントに提供されることを期待しない場合は、キャッシュを無効にします。

共有キャッシュを設定する

NFSマウント内のファイル（存在がチェックされている）が同じクライアント上の別のアプリケーションによって作成された場合（おそらく同じNFSエクスポートへの別のマウントポイントを使用）、クライアント上の単一の共有NFSキャッシュを使用することを検討してください。

sharecacheオプションを使用して、クライアントにNFSマウントをセットアップします。

このオプションは、同じエクスポートを同時に複数回マウントするときに、クライアントのデータキャッシュと属性キャッシュをどのように共有するかを決定します。 同じキャッシュを使用すると、クライアントのメモリ要件が軽減され、同じリモートファイルが異なるマウントポイントを介してアクセスされた場合に、アプリケーションに同一のファイルコンテンツが表示されます。

キャッシングなしのNFSマウントのセットアップ

属性のキャッシュを無効にします。

noacオプションを使用して、NFS共有をクライアントにマウントします。

または、キャッシュされたディレクトリ属性が提供されないようにします。

使用する acdirmin=0,acdirmax=0は、キャッシュタイムアウトを0に設定します（キャッシュを実質的に無効にします）。

ルックアップキャッシュを無視するためのNFSマウントのセットアップ

使用する lookupcache=positive OR lookupcache=none

（利用可能なオプション：all、positiveおよびnone）

NFSマウントを介してディレクトリエントリにアクセスしようとすると、
リクエストされたディレクトリエントリがサーバーに存在する場合、結果はpositiveと呼ばれます。
リクエストされたディレクトリエントリがサーバーに存在しない場合、結果はnegativeと呼ばれます。

lookupcacheオプションが指定されていない場合、またはallが指定されている場合、クライアントは、親ディレクトリのキャッシュされた属性が期限切れになるまで、両方のタイプのディレクトリキャッシュエントリが有効であると見なします。

posまたはpositiveが指定されている場合、クライアントは、親ディレクトリのキャッシュされた属性が期限切れになるまで正のエントリが有効であると想定しますが、アプリケーションが使用できるようにするには、常に負のエントリを再検証します。

noneが指定されている場合、アプリケーションが使用する前に、クライアントは両方のタイプのディレクトリキャッシュエントリを再検証します。これにより、他のクライアントによって作成または削除されたファイルをすばやく検出できますが、アプリケーションとサーバーのパフォーマンスに影響を与える可能性があります。

参照：
1。Linux NFSクライアントでのClose-To-Openキャッシュの整合性
2。NFS-リモートで作成されたファイルをプログラムで検出しますか？
。NFSキャッシュ：サーバーで変更されたときにファイルの内容がクライアントで更新されない
4。NFS man page 。特に "Data And Metadata Coherence"セクション。

11
TheCodeArtist