VFS event hooks in Linux

[Richard Gooch]

Jeremy Allison writes:
> Richard Gooch wrote:
> > 
> > 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.
> 
> Well it works for the kernel oplock code :-).

What exactly is the oplock code, BTW?

> > 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).
> 
> I hope he doesn't mean Samba here. Putting Samba in the kernel
> would be a very *bad* idea :-).

I doubt he means all of it. But perhaps some general interface that
relieves some of the burden off Samba.

> > Somehow I doubt that Samba stat()s a large number of files every 60
> > seconds. It would load the system too much.
> 
> No, that's exactly what it has to do to provide close-to-NT
> ChangeNotify semantics. It has to scan every directory the client
> has expressed an interest in.

OK, in a subsequent message you implied that the protocol notifies
when file attributes (permissions, I presume?) change somewhere in a
directory tree. Is that correct?

So is Samba actually stat()ing all files and directories beneath a
certain point?

I can contemplate stat()ing all directories in a subtree, as that may
only be a few hundred inodes. But stat()ing files too would be
horrendous, since there are likely to be thousands or tens of
thousands of files.

> > 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?
> 
> Client opens a directory. Client issues a ChangeNotify request on
> directory handle to server. Client request completes when change
> occurs (it's a one shot event).

So the client blocks, waiting for notification?

> > 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.
> 
> That works as it is close to the desired semantics (the
> server knows the client has a directory open). The problem
> is that the NT semantics allow a client to set notification
> on a change in a directory *or any subdirectory within it*,
> although how many clients actually use that is open to debate
> (no one has complained about the current Samba behaviour, which
> is only to scan the current directory).

Well, if were to only report changes to directory inodes, then it's
not so bad, as a few hundred fds is not a major worry.

OK, so Samba is only reporting on inode write events for the directory
and its leaf nodes (including regular files)?

Well, that's relatively cheap, as you're only looking at a few dozen
files at most (typical usage). The new poll()-based scheme I've
implemented will handle this easily.

So if Samba is cheating, we can at least make such cheating efficient
on Linux :-)

A separate question is can we stop cheating and pass the Linus
barrier? ;-)

				Regards,

					Richard....