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

[nf <nf2 scheinwelt at>]

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...

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. 

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'?

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).

Regards,

Norbert