VFS event hooks in Linux

[Richard Gooch]

Jeremy Allison writes:
> Richard Gooch wrote:
> > 
> > Following on from some private discussions, it's been brought to my
> > attention that Samba would benefit from VFS event hooks. Could someone
> > please explain what level of support is useful?
> 
> ChangeNotify is the SMB call Samba uses to return to a Windows
> client that a directory tree has been modified and should be
> re-scanned by the client.

So if somewhere deep in a directory tree a change is made, the SMB
client will rescan the *entire* tree?

> ChangeNotify can act just on one directory, or on a complete tree
> (realistically it is only used on a per-directory basis).

Why do you say that? Used by whom? The client or the server?

> > An alternative scheme I'd devised would allow you to keep just a
> > single open file per filesystem, which is used to receive events when
> > any inode in that FS is written to. An event queue would be
> > maintained, to which the inode number would be written.
> > 
> > Is this scheme an improvement? If it is, then please give me your
> > arguments and I'll raise them with Linus.
> 
> That sounds better, and also similar to the kernel oplock
> notification system that was already implemented in IRIX
> for Samba.
> 
> The ideal interface would be one that acted on a direcory
> inode and reported changes in any inode (file or directory)
> hierarchically "under" that inode. If this is not doable,
> then a generic filesystem inode notify is better than nothing,
> although may cause many false positives on a heavily used
> filesystem (a home directory server for example).

This may be possible too. Just tag a directory somewhere under / (it
could even be /), and when an inode changes, walk up the directory
entry tree looking for the tagged inode. You'd maintain a global count
of tagged inodes, so that if it is 0, you can skip the walk.
This would of course slow down inode writes on other filesystems or
parts of the namespace as well.

An alternative would be to make this per-FS. You can tag an inode
anywhere in a FS, which also tags the superblock. You only walk up the
tree if the FS is tagged. Unwatched filesystems would not suffer the
walk penalty.

It would of course require a bit more effort from Samba when exporting
a tree with multiple filesystems beneath it.

> This is good news, as currently Samba has to scan
> each watched directory to notice changes (which it does
> via a configurable, currently 60 second, timeout).

So it always scans every directory in the exported volume?!?

Do the ChangeNotify events apply to directory writes only
(i.e. writing to a regular file is ignored)?

				Regards,

					Richard....