VFS event hooks in Linux

[Richard Gooch]

Robert Sandilands writes:
> 
> On Tue, 29 Jun 1999, Richard Gooch wrote:
> 
> > Jeremy Allison writes:
> > > Richard Gooch wrote:
> > > > 
> > So if somewhere deep in a directory tree a change is made, the SMB
> > client will rescan the *entire* tree?
> 
> If you look at the speed it happens at, it may be possible that Windoze
> work that way :-)
> 
> > 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.
> 
> If I understand correctly it would be very slow. The type of message
> generated needs to be processed as quickly as possible. So having to
> walk trees etc. is not the best idea when performance is an issue.

Actually, walking up the directory entry (dentry) tree would be fairly
fast. The Linux dentry mechanism is extremely fast. The killer would
be if the client then scans a large part of the tree.

> > 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.
> 
> The idea of making it per-FS is a good idea.

Well, I've been talking to Linus about this, and he hates the idea. He
doesn't like the idea of throwing anonymous events to user space,
claiming that it's a bad design.

He suggested that if Samba really needed this information, it might be
better to put it in kernel space so it can cheaply check the inodes (I
presume he was referring to avoiding syscall overheads).

However, putting it in the kernel wouldn't help since many inodes in a
directory tree wouldn't be in the inode cache anyway. So the real
limit is the disc I/O on countless thousands of inode lookups.

Somehow I doubt that Samba stat()s a large number of files every 60
seconds. It would load the system too much. So I'd like to revist the
requirements again. What is actually necessary for SMB support? What
must be done at the server side and what happens at the client side?

Let me come to this from another direction. Suppose that an SMB server
need only send directory upate events to clients that have the
directory open (say in their browser). In that case, it would make
sense for the SMB protocol to have the server know that a client has
the directory open. In that case, the VFS poll() patch I've
implemented for Linux should do fine. You just need one open fd per
client/browser.

Since I don't know SMB at all, I have no idea if this reflects
reality.

				Regards,

					Richard....