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

[nf <nf2 scheinwelt at>]

On Thu, 2004-08-12 at 20:15, Josef Weidendorfer wrote: 
> Hi Norbert,
> 
> [CCed to the nautilus mailing list, as there was the long discussion on 
> no/d/i-notify. Please send replys to me, as I'm not subscribed.]
> 
> I just noted the existance of your simple nonotify patch (via LWN), and 
> thought a little bit about it. Some time ago I was involved with the file 
> notification class in KDE (KDirWatch), and maintain the FAM support there (I 
> added that around 1998), so I think I have some user experience here.
> 
> I never found dnotify to be a good solution, and doubt that inotify will be 
> accepted by the kernel people (resource consumption, DDoS attacks, ...).
> A notification should not occupy arbitrary kernel space not linear to any user 
> quota (e.g. file descriptors). This constrain also seems to prohibit 
> recursive directory watching in the kernel, as paths can be arbitrary long, 
> leading to unknown time for propagation down the hierarchy.
> And if a notify mechanism is based on files or inodes, there is always a big 
> complexity to get it right regarding user permissions. I think it's better to 
> let stat() do the security checks on files, and go with a polling mechanism 
> (including perhaps recursive watching) which is triggered by a kernel 
> notification when there was a change somewhere on a whole device.
> The nonotify patch would be very good here.
> 
> So I think the best is to take the simpliest notification approach thinkable, 
> being a mount point watch notification able to deliver change events of a 
> complete device. Let's call it "mnotify". It should be quite easy to 
> implement in the kernel, as every file/inode knows its device, and thus 
> perhaps has a chance for inclusion.
> 
> To be scalable, event merging and delay of notifications should be done in the 
> kernel, with a minimum delay of 1 second to overcome the problem with the 1 
> second granularity of file modify times: It solves a possible race condition 
> when 2 changes are done within a second: Either the 2 changes are merged and 
> then signalled (no problem), or there are 2 notifications, where the user 
> handler of the first will already see the second change, as it is 1 second 
> delayed.
> 
> The notification delay/merging done by mnotify should be adjustable, to allow 
> for a good user space tradeoff if there are a lot of files which have to be 
> polled after a notification, and files are changed often (e.g. when 
> downloading a large file over a slow network). The user space client should 
> adapt the delay time depending on the number of files it has to watch, and 
> also depending on actual changes seen.
> 
> The opened device needed for this mechanism (e.g. /dev/mnotify) could also be 
> used to deliver the nonotify directory times to user space (e.g. via ioctl).
> Otherwise, I would vote for an interface via /dev/mnotify which involves only 
> ASCII content with read and write support. This would include the ability to 
> call select/poll.
> 
> /dev/mnotify should implicitly also watch /proc/self/mounts, i.e. notify about 
> mount point additions/removals. Reading /dev/mnotify would give you the list 
> of mount points, similar to /proc/self/mounts. By writing, you can request 
> notification for such a mount point, using the delay in seconds as parameter. 
> A delay of 0 would mean canceling the request.
> 
> The whole thing is more or less the polling approach of nonotify without the 
> need to do polling all the time. And on a busy device it will degenerate to 
> polling, but without further resource consumption.
> 
> Note that I think a user level damon like FAM or gamin is needed to do the 
> polling and multiplexing client requests which contain file names. It could 
> adjust the polling frequency for client requests depending on the number of 
> requests and active changes, as said above. To overcome any possible security 
> problems of this damon, there should be one instance per user, started on 
> demand.
> 
> Before designing details, I would like to see comments on this.
> 
> Cheers,
> Josef

Hi Josef,

Good to get positive feedback for my 'nonotify' approach.

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?

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

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

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.

Regards,

Norbert