トップQs
タイムライン
チャット
視点
Inotify
ウィキペディアから
Remove ads
inotify (inode notify) とは、ファイルシステムへの変更を通知するようファイルシステムを拡張して、その変更をアプリケーションに報告するLinuxカーネルサブシステムである。inotifyに先行して存在し、類似の目標を持つdnotifyは、inotifyに取って代わられている。
inotifyはJohn McCutchanが作成し[1]、2005年8月29日にリリースされたLinuxカーネルのバージョン2.6.13で、inotifyはLinuxカーネルメインラインにマージされた[2]。以降のバージョンのLinuxカーネルでは、inotifyはさらに改良されている。GNU Cライブラリ (glibc) では、inotifyに必要なライブラリインタフェースは2006年3月にリリースされたバージョン2.4で追加され、2006年9月にリリースされたバージョン2.5でinotifyを完全にサポートした[3]。
inotifyの主な用途の1つとしては、Beagleなどのデスクトップ検索ユーティリティが挙げられる。inotifyの機能により、数分おきにファイルシステム変更をスキャンするといった非常に効率が悪い作業をせずに、変更されたファイルの再インデックス化が可能となる。
inotifyは、ディレクトリビューの自動更新、設定ファイルの再読み込み、ログの変更、バックアップ、同期、アップロードなどにも使える。
Remove ads
制限
inotifyにより課される制限は以下の通りである:
- inotifyは再帰的なディレクトリ監視をサポートしていない。このため、inotifyによる監視はサブディレクトリ毎に個別に行う必要がある[4]。
- inotifyは、sysfsやprocfsによるイベントは一部しか報告しない。
- inotify経由の通知は、直近に発生したファイルシステムのイベントをカーネルが全て認識していることが前提となっているが、NFSなどのネットワーク接続されたファイルシステムに対してそれが常にできているとは限らない。NFSなどはあるクライアントによる変更をすぐには他のクライアントへブロードキャストしないからである。
- inotifyは改名されたイベントを直接処理しない。つまりinotifyは改名前と改名後のそれぞれにおける2つのイベントを発行する。どの順序でイベントが通知されても良いように、イベントの内容を吟味・照合する必要がある。
Remove ads
歴史
dnotifyに対する利点
inotifyには先行して存在するdnotify APIと比べて利点が多いため、dnotifyはinotifyに置き換えられている[5][6][7]。dnotifyを使う場合、プログラムは監視用としてディレクトリ毎に1つのファイル記述子を使う必要があるため、プロセス毎のファイル記述子制限に到達した場合にボトルネックとなってしまう。後にこの問題を克服したfanotifyが作られた。さらにリムーバブルメディア使用時にdnotifyがファイル記述子を使うと問題があることも判明した。ファイル記述子はリソースをビジー状態に維持するため、デバイスをアンマウントできないからである。
その他のdnotifyの欠点としては、dnotifyの粒状性レベルが挙げられる。プログラマはディレクトリレベルでしか変更を監視できない。通知メッセージが送られた場合に発生する環境の変更に対する詳細な情報にアクセスするためにはstat構造体を使う必要があるが、stat構造体の使用は必要悪とされる。新規に生成されたstat構造体とそれに対応するキャッシュされたstat構造体との比較が、stat構造体が新規生成される度に行われるからである。
inotify APIはプログラマに対し、dnotifyが使うシグナル通知システムではなく、定着したselectとpollインターフェイスを使えるようにしているため、inotify APIが使うファイル記述子はdnotifyが使うそれよりもはるかに少ない。これにより、inotify APIを（GLibなどの）既存のselectやpollベースのライブラリと統合しやすい。
関連項目
- File Alteration Monitor
- DMAPI
- kqueue
- FSEvents
- inotail
脚注
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads