Weekly Edition
Return to the Kernel page
| |||||||||||||
Watching filesystem events with inotify
It is not uncommon for applications to want to know when something happens
within a subtree of a filesystem. File managers are the most obvious
example; if an application creates a new file within a directory
represented in a file manager, users really like to see that new file show
up, quickly. One could also imagine other sorts of applications - such as
security monitoring code or just daemons wanting to know when their
configuration files have changed - which can benefit from being told about
filesystem activity.
The Linux mechanism for communicating filesystem events to user space is called "dnotify." A program watches a directory by opening it, then issuing a fcntl(F_NOTIFY) call. Thereafter, changes in that directory will result in a SIGIO signal being sent to the process, which can then dig through its cached information and try to figure out just what happened. People like to complain about dnotify; the interface is ugly (signals are a pain), it is hard to figure out what the changes are, it requires keeping files open and thus blocks the unmounting of removable media, etc. So there has long been interest in a replacement. The most visible effort in that direction is inotify, which has been under development (by John McCutchan) for some time now; recently Robert Love has jumped in to help the project along. inotify 0.11 was released on September 28, and an increasingly strong push is being made to get it included into -mm for wider exposure and testing. inotify works through a new character pseudo-device. Any application which wants to monitor filesystem activity need only open /dev/inotify and issue one of two ioctl() commands to it:
Quite a few possible events can be watched for: IN_ACCESS (the file was accessed), IN_MODIFY (the file was changed), IN_ATTRIB (file attributes changed), IN_OPEN and IN_CLOSE (for open and close events), IN_MOVED_FROM and IN_MOVED_TO (when files are renamed), IN_CREATE_SUBDIR and IN_DELETE_SUBDIR (creation and deletion of subdirectories), IN_CREATE_FILE and IN_DELETE_FILE (creation and deletion of files within a directory), IN_DELETE_SELF (when a monitored file is deleted), IN_UNMOUNT (when the filesystem containing the file is unmounted), and a couple of others. The events themselves are obtained by simply reading from the device. Thus a program can block on the device itself, or use poll() to incorporate notifications into a larger event-processing loop. No signals are involved. The actual implementation of inotify is relatively simple. The in-core inode structure is augmented with a linked list of processes interested in events involving that inode. When an INOTIFY_WATCH call is made, an entry is made in the corresponding list (and the inode is pinned into memory for the duration). Various parts of the filesystem code get an extra inotify_inode_queue_event() call when an action succeeds. The rest is just the usual overhead of maintaining lists of events for processes, waking those processes up when new events arrive, etc. While most interest and activity seems to be around inotify, it is not the only dnotify replacement in circulation; nonotify is an alternative. There are also some remaining issues about the interface exported by inotify. It has been suggested that the inotify ioctl() calls should take file descriptors rather than file names; that change would eliminate problems in dealing with long file names and would also make access control checks happen automatically. The interface would have to be done in such a way that the application could close the file and still receive events, though; otherwise dnotify's problems with unmount blocking and excessive use of file descriptors would just come back again. These issues notwithstanding, inotify looks like it is headed for inclusion into a mainline kernel in the not-too-distant future. (Log in to post comments)
No more timer Posted Sep 30, 2004 8:54 UTC (Thu) by xav (subscriber, #18536) [Link] Well, the only remaining bad design I saw (perhaps there are others) in inotify was the use of a fixed timer to dispatch events to listening tasks. RML has fixed that this week. Apparently some are still complaining about some quirks here and there, but that means they'll be ironed out soon.
Watching filesystem events with inotify Posted Sep 30, 2004 9:36 UTC (Thu) by rjw (guest, #10415) [Link] I remember long ago reading ( I believe on these very pages) that ioctl() was considered a bit skanky, and really people should be making devices that just need read() & write().
And if one of them has another meaning already, a separate control device should be created.
That way echo & friends can be used to test/use all this functionality...
What happened to this idea?
Watching filesystem events with inotify Posted Sep 30, 2004 13:27 UTC (Thu) by elanthis (guest, #6227) [Link] The ioctl is simply easier to code and use, so it was used.
The inotify developer is quite willing to switch to a write() based interface, if Linus/Andrew decide it's necessary.
Watching filesystem events with inotify Posted Sep 30, 2004 14:18 UTC (Thu) by rjw (guest, #10415) [Link] I wasn't really asking about this specific case.I was just wondering if this principle was still current... it seems like new ioctl() calls are coming thick and fast.
Watching filesystem events with inotify Posted Sep 30, 2004 20:10 UTC (Thu) by elanthis (guest, #6227) [Link] ioctls are still frowned upon, yes. they just happen to have their uses.
Typo Posted Sep 30, 2004 14:20 UTC (Thu) by nhasan (guest, #1699) [Link] IN_CREATE_FILE and IN_DELETE_FILE (creation and creation of files within a directory), IN_DELETE_FILE (when a monitored file is deleted),Can you spot the problem?
Typo Posted Sep 30, 2004 14:22 UTC (Thu) by corbet (editor, #1) [Link] Fixed, thanks.Request: typo reports sent to lwn@lwn.net have a higher chance of being seen and acted upon quickly...
Watching filesystem events with inotify Posted Sep 30, 2004 17:50 UTC (Thu) by bronson (subscriber, #4806) [Link] Is there any chance of getting the locate command to use inotify? Incremental indexing would be sooo nice compared to brinnging my system to its knees at 2:00 every morning.
Does anybody remember ON:Location? That was a pretty amazing piece of software... Of course, writing something like that nowadays would be quite a bit more involved than just patching out a few HFS hooks.
Watching filesystem events with inotify Posted Oct 1, 2004 19:34 UTC (Fri) by joeshaw (guest, #13325) [Link] You might be interested in beagle, which aims to index users' data and integrate it with the desktop. You can follow a lot of the development in the blogs at Planet Beagle.
Watching filesystem events with inotify Posted Oct 2, 2004 9:34 UTC (Sat) by miallen (guest, #10195) [Link] Here, here. Slocate is an abomination. Something about my laptop that causes the system to really freeze up. I turned it off long ago in favor of running it manually once in a while. It's really amazing such a crude technique has lasted this long. It will be a glorious day when slocate is replaced with something that has proper fs/kernel support.
Watching filesystem events with inotify Posted Aug 29, 2005 9:14 UTC (Mon) by gravious (guest, #7662) [Link] erm, check out rlocate :)i use it on gentoo, and it just works (tm)
why not a syscall Posted Oct 7, 2004 20:10 UTC (Thu) by huaz (guest, #10168) [Link] Seems a syscall is more appropriate than a special device interface.
why not a syscall Posted Dec 2, 2004 14:43 UTC (Thu) by fursten (guest, #26401) [Link] My first reaction was "Why not add pioctl and use that?". For those who don't know pioctl: it's a syscall used by AFS and a couple of other remote fs implmementations. It's essentially ioctl on paths instead of file descriptors. This means that you get rid of the dnotify problems with the need of having the watched file open.
I have on the other hand not studied this in any depth...
Watching filesystem events with inotify Posted Jun 21, 2005 18:02 UTC (Tue) by stevef (subscriber, #7712) [Link] file/directory change notification would be particularly useful on network files (remote files accessed through network filesystems such as nfs or cifs, or cluster filesystems). The current D_NOTIFY fcntl can be intercepted by a filesystem.
Can filesystems intercept inotify?
Watching filesystem events with inotify Posted Nov 18, 2005 13:03 UTC (Fri) by Drevic (guest, #33945) [Link] INOTIFY on SUSE 10.0 Linux
Starting from kernel 2.6.13, inotify is part of the kernel.
inotify_init
Please see my web page to find out more details:
Tutorial with code examples Posted Jan 23, 2006 19:50 UTC (Mon) by dmarti (subscriber, #11625) [Link] Robert Love's tutorial Intro to inotify has good code examples (using a 2.6.13 kernel).
|
|||||||||||||