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

[Josef Weidendorfer <Josef Weidendorfer gmx de>]

On Friday 13 August 2004 22:14, nf wrote:
> On Thu, 2004-08-12 at 20:15, Josef Weidendorfer wrote:
> > [proposal of a moint point notification mechanism]

> I think it is a very good idea to do change detection on device basis
> before checking the directories. Also because John McCutchan (author of
> inotify) pointed out rightly that stat() calls can also block umount -
> although that will happen rarely.
>
> But do you think it is really necessary to use an event mechanism to
> notify userspace programs of changes on a device?

Actually I can see only one reason for it: there seems to be some 
interest/trend to get a "tick-less" Linux system. With "tick" I mean the 
timer interrupt of the kernel for scheduling, timers and so on. Often, ticks 
can be skipped if the system is idle. This way, a processor sleeping in a 
power mode on a laptop does not have to be waken up, leading to less power 
consumption. In this scenario, polling done by user applications is not a 
fine behavior.
At least here, a light-weight notification mechanism seems to be useful.

> Maybe it would be sufficient to store the file modification dates not
> only in the parent directories but also in a field in the device
> superblock: The userspace client would only have to poll the
> 'mcontents_mtime' [1] of the mounted devices and, only if it has
> changed, poll the 'dcontents_mtime' [2] of the directories on the
> device. That would also reduce the idle activity to almost zero, but
> without the need of a complex event queuing and grouping mechanism
> inside the kernel. (But to be honest, i don't know how that kernel event
> stuff works).

Your idea about changing a device attribute on any change of a device seems to 
be very interesting, I didn't thought about that possibility. To overcome 
racy conditions, I would delay changes to this device attribute a 
configurable amount of time (at least 1 second) after a change happened, and 
make the minimum a per-device setting to for the administrator.

> [1] Mountpoint contents modification time
> [2] Directory contents modification time
>
> I also like your idea to use ioctl() for polling, because modifying the
> stat() syscall would hardly get accepted by the kernel people. Do you
> know if ioctl calls also allow to check which user has invoked them (as
> with syscalls), to check if he is allowed to dive into a certain
> directory.

That was only a quick idea; an extension to stat seems to be much more 
elegant. Of course, ioctl's should allow for the same permission changes. 

> Concerning the userspace daemon: I don't know if it is really necessary
> from a pragmatic point of view - I'm always in favour of keeping things
> simple. Maybe it would be less resource intensive if the polling is
> triggerd by the apps directly. They could for instance simply use
> GUI-timers, thus not requiring an extra process and not requiring
> inter-process communication. In that case the m/nonotify client library
> could just be 'passive'. But i think that's a statistical question of
> how many apps tend to watch the same directories. If that happens a lot,
> multiplexing certainly would be a good thing.

I think there is no need for a daemon on a single desktop machine. That is 
needed for NFS mount dirs, where a file server has to serve multiple clients.
Polling can be a big problem for such a NFS server, so here there should be a 
special network-wide file notification service. The nice thing: FAM does it 
already.

Cheers,
Josef

>
> Regards,
>
> Norbert