Linux Kernel 2.6 Documentation:
/usr/src/linux/Documentation/filesystems/inotify.txt
filesystems/inotify.txt
強力で単純なファイル変更通知システム
[プレインテキスト版]
- 原著作者: Robert Love <rml_at_novell.com>
- 翻訳者: Seiji Kaneko < skaneko at mbn dot or dot jp >
- バージョン: 2.6.26.5
- 翻訳日時: 2008/11/29
=========================================================
これは、
linux-2.6.26.5/Documentation/filesystems/inotify.txt の和訳
です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
更新日 ： 2008/10/15
翻訳者 ： Seiji Kaneko < skaneko at mbn dot or dot jp >
=========================================================
inotify
# a powerful yet simple file change notification system
強力で単純なファイル変更通知システム
#Document started 15 Mar 2005 by Robert Love <rml@novell.com>
文書化は 15 Mar 2005 に Robert Love <rml@novell.com> さんによって開始されま
した。
#(i) User Interface
(i) ユーザインターフェース
#Inotify is controlled by a set of three system calls and normal file I/O on a
#returned file descriptor.
Inotify は 3 つのシステムコールの組と、返されたファイルディスクリプタに対す
る通常の I/O で制御されます。
#First step in using inotify is to initialise an inotify instance:
inotify を使うための最初の手順は、inotify インスタンスを初期化することです。
int fd = inotify_init ();
#Each instance is associated with a unique, ordered queue.
各インスタンスは、順序づけられたインスタンス別のキューに関連づけられています。
#Change events are managed by "watches". A watch is an (object,mask) pair where
#the object is a file or directory and the mask is a bit mask of one or more
#inotify events that the application wishes to receive. See <linux/inotify.h>
#for valid events. A watch is referenced by a watch descriptor, or wd.
更新イベントは、"watch" 群で管理されます。各 watch (監視) は (対象, マスク)
のペアであり、対象とは一つのファイルまたはディレクトリで、マスクはビットマス
クであり、アプリケーションが受けたいと思う inotify イベントを一つないしは複
数指定します。有効なイベントについては <linux/inotify.h> を参照ください。
watch は watch ディスクリプタ (wd) を使って参照されます。
#Watches are added via a path to the file.
watch は、ファイルへのパスを使って付加されます。
#Watches on a directory will return events on any files inside of the directory.
ディレクトリに対する watch は、ディレクトリ内のどのファイルに対するイベント
も報告します。
#Adding a watch is simple:
watch を追加するのは簡単です。
int wd = inotify_add_watch (fd, path, mask);
#Where "fd" is the return value from inotify_init(), path is the path to the
#object to watch, and mask is the watch mask (see <linux/inotify.h>).
ここで wd は inotify_init() の戻り値であり、path は監視対象のパスであり、
mask は watch マスクです (<linux/inotify.h> 参照)。
#You can update an existing watch in the same manner, by passing in a new mask.
新しい mask を与えることにより、同じ手順で既存の watch を更新できます。
#An existing watch is removed via
既存の watch は以下の手順で削除できます。
int ret = inotify_rm_watch (fd, wd);
#Events are provided in the form of an inotify_event structure that is read(2)
#from a given inotify instance. The filename is of dynamic length and follows
#the struct. It is of size len. The filename is padded with null bytes to
#ensure proper alignment. This padding is reflected in len.
イベントは inotify_event 構造体の形で提供され、与えられた inotify インスタン
スから読む (read(2)) ことができます。ファイル名は動的に長さが設定され、構造
体に続きます。名前長は size len です。ファイル名は適切なアラインメントとなる
よう null バイトでパディングされます。len はパディングを含んだ長さです。
#You can slurp multiple events by passing a large buffer, for example
複数のイベントを長いバッファを与えることによってためておくことができます。
例えば
size_t len = read (fd, buf, BUF_LEN);
#Where "buf" is a pointer to an array of "inotify_event" structures at least
#BUF_LEN bytes in size. The above example will return as many events as are
#available and fit in BUF_LEN.
ここで、buf は "inotify_event" 構造体配列へのポインタで、少なくとも BUF_LEN
バイトのサイズがあります。上記の例では、BUF_LEN に格納できる、かつ提供可能な
数のイベントが返されます。
#Each inotify instance fd is also select()- and poll()-able.
各 inotify インスタンスのファイルディスクリプタは select() や poll() の実行
可能です。
#You can find the size of the current event queue via the standard FIONREAD
#ioctl on the fd returned by inotify_init().
現在のイベントキューの長さは、inotify_init() が返したファイルディスクリプタ
に対して標準の FIONREAD ioctl を発行することにより知ることができます。
#All watches are destroyed and cleaned up on close.
すべての watch はクローズ時に破壊させ、綺麗にされます。
#(ii) Prototypes:
(ii) プロトタイプ:
int inotify_init (void);
int inotify_add_watch (int fd, const char *path, __u32 mask);
int inotify_rm_watch (int fd, __u32 mask);
#(iii) Kernel Interface
(iii) カーネルインターフェース
#Inotify's kernel API consists a set of functions for managing watches and an
#event callback.
Inotify のカーネル API は、watch を管理しイベントを持ち帰るための幾つかの関数
からなっています。
#To use the kernel API, you must first initialize an inotify instance with a set
#of inotify_operations. You are given an opaque inotify_handle, which you use
#for any further calls to inotify.
カーネル API を使うためには、まず inotify インスタンスを一連の inotify 操作
関数で初期化しなければいけません。これにより、以降の inotify を用いた呼び出
しを行なうのに使う、未割り当ての inotify_handle を入手できます。
struct inotify_handle *ih = inotify_init(my_event_handler);
#You must provide a function for processing events and a function for destroying
#the inotify watch.
イベントを処理する関数と、inotify watch を破棄する関数を用意しなければいけ
ません。
void handle_event(struct inotify_watch *watch, u32 wd, u32 mask,
u32 cookie, const char *name, struct inode *inode)
# watch - the pointer to the inotify_watch that triggered this call
# wd - the watch descriptor
# mask - describes the event that occurred
# cookie - an identifier for synchronizing events
# name - the dentry name for affected files in a directory-based event
# inode - the affected inode in a directory-based event
watch - この呼び出しを発生させた inotify_watch へのポインタ
wd - watch ディスクリプタ
mask - 発生したイベントを記載する
cookie - 同期イベントの識別子
name - ディレクトリベースのイベントの場合、影響を受けたファイルの
dentry 名
inode -ディレクトリベースのイベントの場合、影響を受けた inode
void destroy_watch(struct inotify_watch *watch)
#You may add watches by providing a pre-allocated and initialized inotify_watch
#structure and specifying the inode to watch along with an inotify event mask.
#You must pin the inode during the call. You will likely wish to embed the
#inotify_watch structure in a structure of your own which contains other
#information about the watch. Once you add an inotify watch, it is immediately
#subject to removal depending on filesystem events. You must grab a reference if
#you depend on the watch hanging around after the call.
事前に割り当てられて初期化された inotify_watch 構造体を作成し、さらに監視対
象となる inode と inotify イベントマスクを指定することにより watch を追加で
きます。呼び出し時には inode を固定しておかなければいけません。また、
inotify_watch 構造体を埋め込んで、さらに watch に関する情報を格納した自前の
構造体が欲しくなるでしょう。inotify_watch を追加した後は、直後からファイル
システムイベントの結果による削除の対象となります。呼び出し後 watch が残って
いてほしいならば、ポインタをつかんだままにしておかなければなりません。
# inotify_init_watch(&my_watch->iwatch);
# inotify_get_watch(&my_watch->iwatch); // optional
# s32 wd = inotify_add_watch(ih, &my_watch->iwatch, inode, mask);
# inotify_put_watch(&my_watch->iwatch); // optional
inotify_init_watch(&my_watch->iwatch);
inotify_get_watch(&my_watch->iwatch); // オプション
s32 wd = inotify_add_watch(ih, &my_watch->iwatch, inode, mask);
inotify_put_watch(&my_watch->iwatch); // オプション
#You may use the watch descriptor (wd) or the address of the inotify_watch for
#other inotify operations. You must not directly read or manipulate data in the
#inotify_watch. Additionally, you must not call inotify_add_watch() more than
#once for a given inotify_watch structure, unless you have first called either
#inotify_rm_watch() or inotify_rm_wd().
watch ディスクリプタ (wd) と inotify_watch のアドレスのどちらも inotify 操作
に用いることができます。inotify_watch の内部のデータを直接読み書きしてはいけ
ません。また、特定の inotify_watch 構造体に対して、まず inotify_rm_watch() か
inotify_rm_wd() のいずれかを呼ばずに、二回以上 inotify_add_watch() を呼んでは
いけません。
#To determine if you have already registered a watch for a given inode, you may
#call inotify_find_watch(), which gives you both the wd and the watch pointer for
#the inotify_watch, or an error if the watch does not exist.
特定の inode に対して既に watch を登録しているかを確認するには、
inotify_find_watch() を呼んでください。これにより inotify_watch の wd と watch
ポインタの両方が得られ、watch が存在しないならエラーになります。
wd = inotify_find_watch(ih, inode, &watchp);
#You may use container_of() on the watch pointer to access your own data
#associated with a given watch. When an existing watch is found,
#inotify_find_watch() bumps the refcount before releasing its locks. You must
#put that reference with:
watch ポインタの container_of() を使って、指定の watch に関連づけられている自
前のデータにアクセスを行なうことができます。既存の watch が存在する場合、
inotify_find_watch() はロック解放前に refcount を叩き (+1) ます。この参照
は以下のようにしなければいけません。
put_inotify_watch(watchp);
#Call inotify_find_update_watch() to update the event mask for an existing watch.
#inotify_find_update_watch() returns the wd of the updated watch, or an error if
#the watch does not exist.
既存の watch のイベントマスクを更新するには inotify_find_update_watch() を呼
んでください。inotify_find_update_watch() は更新された watch の wd を返しま
すが、watch が存在しない場合にはエラーを返します。
wd = inotify_find_update_watch(ih, inode, mask);
#An existing watch may be removed by calling either inotify_rm_watch() or
#inotify_rm_wd().
既存の watch は inotify_rm_watch() か inotify_rm_wd() を呼ぶことにより削除さ
れます。
int ret = inotify_rm_watch(ih, &my_watch->iwatch);
int ret = inotify_rm_wd(ih, wd);
#A watch may be removed while executing your event handler with the following:
作成したイベントハンドラの中から watch を以下のように削除することもできます。
inotify_remove_watch_locked(ih, iwatch);
#Call inotify_destroy() to remove all watches from your inotify instance and
#release it. If there are no outstanding references, inotify_destroy() will call
#your destroy_watch op for each watch.
inotify インスタンスからすべての watch を削除し、解放するには inotify_destroy()
を呼びます。残った参照がない場合には、inotify_destroy() はあなたの作成した
destory_watch を各 watch につき呼び出します。
inotify_destroy(ih);
#When inotify removes a watch, it sends an IN_IGNORED event to your callback.
#You may use this event as an indication to free the watch memory. Note that
#inotify may remove a watch due to filesystem events, as well as by your request.
#If you use IN_ONESHOT, inotify will remove the watch after the first event, at
#which point you may call the final inotify_put_watch.
inotify が watch を削除する際には、呼び元に IN_IGNORED イベントが送られます。
このイベントを watch メモリの解放を示すものとして使うことができます。ただ、
inotify はあなたの要求以外に、ファイルシステムイベントで watch を削除する場
合もあります。IN_ONESHOT を使う場合、inotify は最初のイベントで watch を削
除します。この時点で最後の inotify_put_watch を呼ぶこともできます。
#(iv) Kernel Interface Prototypes
(iv) カーネルインターフェースプロトタイプ
struct inotify_handle *inotify_init(struct inotify_operations *ops);
inotify_init_watch(struct inotify_watch *watch);
s32 inotify_add_watch(struct inotify_handle *ih,
struct inotify_watch *watch,
struct inode *inode, u32 mask);
s32 inotify_find_watch(struct inotify_handle *ih, struct inode *inode,
struct inotify_watch **watchp);
s32 inotify_find_update_watch(struct inotify_handle *ih,
struct inode *inode, u32 mask);
int inotify_rm_wd(struct inotify_handle *ih, u32 wd);
int inotify_rm_watch(struct inotify_handle *ih,
struct inotify_watch *watch);
void inotify_remove_watch_locked(struct inotify_handle *ih,
struct inotify_watch *watch);
void inotify_destroy(struct inotify_handle *ih);
void get_inotify_watch(struct inotify_watch *watch);
void put_inotify_watch(struct inotify_watch *watch);
#(v) Internal Kernel Implementation
(v) 内部のカーネル実装
#Each inotify instance is represented by an inotify_handle structure.
#Inotify's userspace consumers also have an inotify_device which is
#associated with the inotify_handle, and on which events are queued.
各 inotify インスタンスは inotify_handle 構造体で実現されています。Inotify
のユーザ空間の受け側は、inotify_handle に結びつけられた inotify_device を持ち
イベントはそこにキューイングされます。
#Each watch is associated with an inotify_watch structure. Watches are chained
#off of each associated inotify_handle and each associated inode.
各 watch は inotify_watch 構造体に関連づけられています。watch は関連づけら
れた inotify_handle と関連づけられた inode を結びつけたものです。
#See fs/inotify.c and fs/inotify_user.c for the locking and lifetime rules.
ロックと生存時間に関する規則については fs/inotify.c と fs/inotify_user.c を
参照ください。
#(vi) Rationale
(vi) 解説
#Q: What is the design decision behind not tying the watch to the open fd of
# the watched object?
Q; 監視対象のオブジェクトの、オープンされているファイルディスクリプタを監視し
ないという設計判断の理由を教えてください。
#A: Watches are associated with an open inotify device, not an open file.
# This solves the primary problem with dnotify: keeping the file open pins
# the file and thus, worse, pins the mount. Dnotify is therefore infeasible
# for use on a desktop system with removable media as the media cannot be
# unmounted. Watching a file should not require that it be open.
A: watch はオープンされた inotify デバイスに結びつけられており、オープンさ
れたファイルではありません。これによって dnotify の最大の問題 (ファイル
をオープンし続けることによってファイルを固定、さらにマウントを固定してし
まうと言う問題) が解決されます。この問題により、dnotify はリムーバブルメ
ディアをもつデスクトップシステムには向いていませんでした。メディアがアン
マウントできず、抜けなくなってしまうためです。ファイルの監視、つまり
watch には、ファイルを開くことが要求されていてはならないのです。
#Q: What is the design decision behind using an-fd-per-instance as opposed to
# an fd-per-watch?
Q: ファイルディスクリプタ毎に watch ではなく、ファイルディスクリプタ毎にイン
スタンスとした設計判断の理由は？
#A: An fd-per-watch quickly consumes more file descriptors than are allowed,
# more fd's than are feasible to manage, and more fd's than are optimally
# select()-able. Yes, root can bump the per-process fd limit and yes, users
# can use epoll, but requiring both is a silly and extraneous requirement.
# A watch consumes less memory than an open file, separating the number
# spaces is thus sensible. The current design is what user-space developers
# want: Users initialize inotify, once, and add n watches, requiring but one
# fd and no twiddling with fd limits. Initializing an inotify instance two
# thousand times is silly. If we can implement user-space's preferences
# cleanly--and we can, the idr layer makes stuff like this trivial--then we
# should.
A: ファイルディスクリプタ毎に watch を置く実装は許されるファイルディスクリ
プタ (fd) 数の上限、つまり扱いやすい範囲の上限を超えてしまいますし、
select() で扱うのに適した数も超えてしまいます。そう、root ならプロセス毎
の fd 数の上限は超えられますし、ユーザは epoll を使うこともできます。でも
その両方を要求するのは馬鹿げた、過剰な要求でしょう。watch は開いているフ
ァイルよりメモリを食いませんし、この理由でこの二つの数は分けるほうが妥当
なんです。
現在の実装はユーザ空間の開発者が望むもの、つまりユーザは一度だけ inotify
を初期化し、そして n 個の watch を加えますが、必要なファイルディスクリプ
タは一つで、fd 数の上限を気にする必要はありません、という要望そのものの実
装になっています。inotify インスタンスを何千回も初期化するのは馬鹿げていま
す。もし私たちがユーザ空間での要望を綺麗に実装できるなら、そしてそれは可
能で、そうすべきことなのです。これは idr レイヤによりごく容易に実現できて
います。
# There are other good arguments. With a single fd, there is a single
# item to block on, which is mapped to a single queue of events. The single
# fd returns all watch events and also any potential out-of-band data. If
# every fd was a separate watch,
これ以外にも良い理由があります。一つの fd を使った場合、ブロックする対
象はひとつになり、それはイベントの単一のキューに対応付けられます。この
単一の fd が全 watch イベントを返しますし、アウトオブバンドのデータが
あればそれも格納できます。もし各 fd が別々の watch に対応付けられてい
たなら、
# - There would be no way to get event ordering. Events on file foo and
# file bar would pop poll() on both fd's, but there would be no way to tell
# which happened first. A single queue trivially gives you ordering. Such
# ordering is crucial to existing applications such as Beagle. Imagine
# "mv a b ; mv b a" events without ordering.
- イベントの順序を付ける方法がない。ファイル foo とファイル bar で、両方
の fd に対して poll() が発生することがありますが、どちらが先に起こったの
かを知る方法がありません。キューが一つなら無論順序は決まります。このよう
な順序づけは Beagle のような既存のアプリケーションで必須になっています。
例えば、"mv a b ; mv b a" イベントに順序がなかったら大変です。
# - We'd have to maintain n fd's and n internal queues with state,
# versus just one. It is a lot messier in the kernel. A single, linear
# queue is the data structure that makes sense.
- 一つではなく、n 個の fd と n 個の状態を持った内部キューを管理する必要が
あります。これはカーネルをはるかにごちゃごちゃにします。単一の、線形のキ
ューが妥当なデータ構造なのです。
# - User-space developers prefer the current API. The Beagle guys, for
# example, love it. Trust me, I asked. It is not a surprise: Who'd want
# to manage and block on 1000 fd's via select?
- ユーザ空間の開発者は、既存の API を望みます。Beagle の開発者は、例えば、
これが大好きです。まあ私を信用してください。驚きはないようにしていますか
ら。なんとなれば、だれが 1000 個の fd を select で管理・ブロックしたいと
思うんですか？
# - No way to get out of band data.
- アウトオブバンドのデータを得る方法がない。
# - 1024 is still too low. ;-)
- 1024 はまだ小さすぎる ;-)
# When you talk about designing a file change notification system that
# scales to 1000s of directories, juggling 1000s of fd's just does not seem
# the right interface. It is too heavy.
何千というディレクトリに拡大するファイル変更通知システムの設計では、何千と
いう fd をお手玉するのは正しいインターフェースではないんです。あまりに重す
ぎます。
# Additionally, it _is_ possible to more than one instance and
# juggle more than one queue and thus more than one associated fd. There
# need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
# process can easily want more than one queue.
また、一つ以上のインスタンス、一つ以上のキューの操作、そして関連づけられた
一つ以上の fd を持つことも可能です。別に、プロセス毎に一つの fd という必要
があるわけではありません。一つのキューに一つの fd ということであり、プロセ
スは容易に二つ以上のキューを持つこともできます。
#Q: Why the system call approach?
Q: システムコールというアプローチを取ったのはなぜですか。
#A: The poor user-space interface is the second biggest problem with dnotify.
# Signals are a terrible, terrible interface for file notification. Or for
# anything, for that matter. The ideal solution, from all perspectives, is a
# file descriptor-based one that allows basic file I/O and poll/select.
# Obtaining the fd and managing the watches could have been done either via a
# device file or a family of new system calls. We decided to implement a
# family of system calls because that is the preferred approach for new kernel
# interfaces. The only real difference was whether we wanted to use open(2)
# and ioctl(2) or a couple of new system calls. System calls beat ioctls.
A: ユーザスペースインターフェースの貧しさが dnotify の二番目に大きな問題です。
ファイル通知のためのシグナルは、実に、実にひどいインターフェースです。この
種の問題には、すべて適していないでしょう。あらゆる面で理想的な解決策は、フ
ァイルディスクリプタベースで基本 I/O と poll/select を受けられるものです。
fd を入手して watch を管理するのは、デバイスファイルを使う方法でも、一連の
システムコールの新設のいずれでも可能でした。一連のシステムコールを準備する
方を選んだのは、新しいカーネルインターフェースにはそちらの方が適していたか
らです。本当の違いとは、open(2) と ioctl(2) を使うか、新システムコールを使
うか、だけにすぎないのです。システムコールの方が ioctl よりも良いに決まっ
ています。
Linux カーネル 2.6 付属文書一覧へ戻る