VFS event hooks in Linux

[Robert Sandilands]

On Wed, 30 Jun 1999, Richard Gooch wrote:

> Robert Sandilands writes:
> > 
> > On Tue, 29 Jun 1999, Richard Gooch wrote:
> > 
> > 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.

I'm a pessimist, always work on worst case scenarios... Doing lost of very
fast things end up being slow... And with this type of thing speed is very
important...

> > 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 is right... But you have to make a compromise between what is good
design and what is speed-efficient code. I know it is a Microsoft attitude
but we will hopefully make certain it works all the time and not only some
of the time :-)

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

Why do you want to do thousands of inode lookups ? The cost would be
horendous no matter how fast a single lookup happens. You would be doing a
huge amount of them every second.
 
> 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?

I'm talking from a slightly selfish point of view here... I would like to
be able to implement on-access scanning of samba shares.. For that I need
to know whenever a file is created, opened and/or closed. This would be a
hook implemented into samba itself or into the kernel ? This will happen
on the file-serving machine. 

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

For this type of application the directory only needs to be updated for
every client about once a minute or whenever the client requests a
refresh. Speed requirements here would not be important and only the fact
that a change occured is needed, not what the change was.

_________________________________________________________________________
Silly little things like representing anybody else is not of importance
-------------------------------------------------------------------------
       Robert Sandilands - Peace is when the music of the soul
                 harmonizes with the music of Life
 Tel: +27-12-841-2106, Fax: +27-12-841-4670, Email: robert at vps.co.za
-------------------------------------------------------------------------