Re: [RFC][PATCH] inotify 0.9

From: Robert Love
Date: Wed Sep 15 2004 - 13:07:58 EST


On Wed, 2004-09-15 at 11:52 -0400, John McCutchan wrote:

> I am interested in getting inotify included in the mm tree.
>
> Inotify is designed as a replacement for dnotify. The key difference's
> are that inotify does not require the file to be opened to watch it,
> when you are watching something with inotify it can go away (if path
> is unmounted) and you will be sent an event telling you it is gone and
> events are delivered over a fd not by using signals.

I want to expand on why dnotify is awful and why inotify is a great
replacement, because dnotify's limitations are really showing up on
modern desktop systems.

Some technical issues with dnotify and why inotify solves the problem:

- dnotify requires one fd per watched directory. this results
in a lot of file descriptors if you are trying to do anything
creative. inotify solves this by only having one open file
descriptor.

- with dnotify, you open the fd on the directory to watch, which
pins the directory. this makes unmounting the backing
filesystem impossible and means using dnotify on removable
devices is nontrivial. This is a problem with desktop systems.
Not only does inotify solve this problem (by not requiring an
open of each watched directory), but it even sends an "unmount"
event when the watched directory is unmounted.

- Using dnotify is, uh, interesting. I mean, fcntl(2) and
SIGIO? You end up needing to use real-time signals. Gross
gross gross. This does not working well with modern event-
driven applications that use mainloops. You end up needing a
complicated daemon like FAM. We don't want FAM, and in fact we
should not even need a daemon (although we might want one).
Conversely, inotify is trivial to use and integrates well and is
select()-able.

I have been going over the code for awhile now, and it looks good. I
would really like to hear Al's opinion so we can move on fixing any
possible issues that he has.

Best,

Robert Love


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/