Re: mnotify: mixing nonotify & simple mount watching (Was: Re: [RFC/PATCH] Nonotify...)

[John McCutchan <ttb tentacle dhs org>]

On Sat, 2004-08-14 at 08:03, nf wrote:
> On Sat, 2004-08-14 at 03:36, John McCutchan wrote:
> > Just to remind people who are interested in this problem:
> > 
> > Inotify patches for linux-2.6.7 were posted on the gamin list recently,
> > and using gamin CVS everything works perfeclty, and doesn't block
> > unmount. In short: this problem has been solved and I haven't found a
> > bug in inotify in 2 weeks.
> > 
> > John
> 
> Hi John,
> 
> Actually i have compiled inotify 0.5 into my kernel already and played
> with it a bit (just the command line client). It's cool and i hope you
> can convince the kernel maintainers ... although i still think
> generating events is a bit of an overkill, because you need to aggregate
> them on the client side with timers anyway...

inotify 0.5 is very old. You should try a newer version (I will put up a
new patch for linux-2.6.8.1 soon). Checking for events is very cheap and
you don't need timers, just use select() like all unix apps.

> 
> Just a number of questions:
> 
> 1) Can it happen with inotify that events get lost when the system is
> very busy? In that case the inotify client needs to receive some kind of
> "event-queue congestion"-event to know that events got lost and it has
> to reread all the directories it is monitoring to see the changes. 

Yes, this is something on my todo list.

> 
> The inotify event queues in the kernel could have the length N+1 with 1
> element extra space to attach a single "congestion-event" at the end...
> 
> 2) Can any user request change notification via /dev/inotify or only
> root? Do you check users permissions with something like
> 'user_path_walk'?

Any user that can open /dev/inotify can request notification. So
the policy is up to the system admin. Yes user_path_walk checks 
file permissions and will not allow an unprivileged user to
watch files that they don't have permission to.

> 
> 3) Could the concepts of inotify and nonotify be merged? I think it
> shouldn't be to hard to add a 'dcontents_mtime' field to the objects you
> attach to the directory inodes and set it whenever an event gets raised.
> Maybe this would also help when recovering from queue congestion is
> necessary (To know which directories have to be reread by the client).

I don't see the point in having dcontents_mtime, inotify will tell you 
when an event happens and as long as the app and system behave properly
the queue should never over flow. dcontents_mtime just seems like kludge
around an program bug. If an app lets the queue over flow, it might as
well re-stat everything. 

On a gnome 2.6 there are only 23 files/directories being watched at a
time (plus however many nautilus windows you have open) so the time it
takes to re-stat all of these directories is moot.

John