VFS event hooks in Linux

[Greg Dickie]

This is REALLY not my area of expertise but I'm sure Jeremy will know more
about this. IRIX has a thing called a FAM (File alteration monitor) which I
believe has a similar function to what you are looking for. Perhaps you could
mimic that mechanism and it would be enough?

Greg

On 29-Jun-99 Richard Gooch wrote:
> 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....

---------------------------------------------------------------------
Greg Dickie
Just A Guy*
*from discreet (the logic is gone)
Montreal 
(514) 954-7171
greg at discreet.com