missing code in fcntl_dirnotify

I noticed that fcntl_dirnotify in fs/dnotify.c is missing logic to call an optional fs specific inode operation for file/directory notify. Since directory and file notification to make any sense for many filesystems (especially network ones) would require that this call (fcntl F_NOTIFY) to pass through to the filesystem who owns the inode (to let the particular filesystem know it has to call dnotify_parent on remote updates to the file/directory) it seems like a bug. Without notification to the underlying network filesystem, it can not know to read the updated inode->i_dnotify_mask Is there any objection why dnotify_parent should not be added to ksysm.c and to adding an optional inode_operation for change_notify so filesystems that can support change notify (cifs, nfs, presumably afs etc.) could do change notify to the proper kernel routine(dnotify_parent)?

Hi Steven,

Less a bug - more a design feature :-)

No objection whatsoever. At the time we implemented dnotify, we did not need it to work on networked file systems (at least for remote events) and we were not confident enough of ourselves or our understanding of the file system code (locking in particular) to attempt this. So we documented it ... :-) (see Documentation/dnotify.txt)

You probably need to add __inode_dir_notify as well (I think).

Cheers,
Stephen Rothwell                    [email protected]
http://www.canb.auug.org.au/~sfr/

P.S. Are you the Steven French from IBM in Austin?  Because I am the
Stephen Rothwell from IBM LTC Ozlabs in Canberra (in case it wasn't
obvious).

Note that local dnotify has well defined ordering, such that if you know the underlying filesystem is local, stat() results can be safely cached until a dnotify event is received, and dnotify events that are sent are available to the target task immediately, without delay.

This is quite useful, when recreating a cached web page or program file would require a stat() of all its component source files and databases, as you can avoid all of them and just see whether you received a dnotify before the page request. This makes it feasible to do accurate cacheing on every request.

At the moment, it's necessary to only use this feature if it's known to be a local filesystem time, or if it's known that only the local host modifies the files.

When dnotify is added for network filesystems, it seems likely that the well defined ordering would be relaxed - that you'd expect to see the dnotify _eventually_, rather than guaranteed to see it as soon as a file is changed. (NFS does not return up to date stat() results either, so dnotify is not the only thing which is relaxed).

It would be great if there were some way for the application to be told which kind of dnotify ordering it is getting (immediate or delayed), and of course whether it will get them at all for files modified remotely.

Cheers,
- Jamie