inotify が機能するには、カーネルからのサポートが必要です。アプリケーションがディレクトリを追跡するとき、それらの変更が発生したときにカーネルに通知するように要求します。変更が発生すると、それらの変更をディスクに書き込むだけでなく、カーネルは監視プロセスにも通知します。
リモート NFS マシンでは、変更はカーネルから見えません。それは完全にリモートで行われます。NFS は inotify より前から存在しており、NFS やそれに相当するネットワーク レベルのサポートはありません。
これを回避したい場合は、リモート マシンの inotify リクエストを仲介するサービスをストレージ サーバー上で実行し (カーネルは常にファイル システムへの変更を確認するため)、データをリモート クライアントに転送します。
編集: inotify をサポートしていないことをNFSのせいにするの は奇妙に思えます。
Network File System (NFS) は、1984年にSun Microsystemsによって最初に開発された分散ファイル システム プロトコルです。ウィキペディアの記事
でも:
inotify (inode 通知) は、ファイルシステムを拡張してファイルシステムへの変更を通知するように機能するLinux カーネル サブシステムです。[...] リリース 2.6.13 ( 2005 年6 月 18 日) からメインラインの Linux カーネルに含まれています[...]。ウィキペディアの記事
移植可能なネットワーク プロトコル/アプリケーションが、別のオペレーティング システム用に開発され、20 年以上後に登場した特定のカーネル機能をサポートすることを期待するのは困難です。拡張機能が含まれていたとしても、他のオペレーティング システムでは使用できず、役に立ちません。
*すべてのケースで地雷を強調
これには別の問題があります。ネットワークをまったく使用しておらず、適切な inotify サポートを備えたローカル ファイルシステムを使用しているとします: ext3 (でマウントされているとします/mnt/foo
)。ただし、実際のディスクの代わりに、ファイルシステムはループバック デバイスからマウントされます。基になるファイルは、vfs 内の別の場所 (たとえば、/var/images/foo.img
) でアクセスできます。
ここで、マウントされた ext3 ファイルシステムを変更することは想定されていませんが、変更がメタデータではなくファイルの内容に対するものである場合は、変更してもかなり安全です。
したがって、賢明なユーザー/var/images/foo.img
が 16 進エディタでファイル システム イメージ ( ) を変更し、ファイルの内容を他のデータに置き換え、同時に inotify ウォッチがマウントされたファイル システム上の同じファイルを監視しているとします。
inotify が監視プロセスにこの種の変更を常に通知するように調整できる合理的な方法はありません。ext3 に通知して変更を反映させるためには、多少の変更が必要になる可能性がありますが、たとえば xfs ドライバーには適用されません。
また、そうすべきではありません。あなたは浮気している !inotify は、監視されている実際のマウントポイントで vfs を介して発生した変更のみを通知できます。その VFS の外部で変更が発生した場合、基礎となるデータの変更が原因で、inotify は役に立たず、その問題を解決するようには設計されていません。
ネットワーク通知にメッセージ キューを使用することを検討しましたか?