VFS event hooks in Linux
Greg Dickie
greg at discreet.com
Tue Jun 29 14:35:19 GMT 1999
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
More information about the samba-technical
mailing list