Fw: Re: Implemented OPLOCK for FreeBsd

Jonathan Lemon jlemon at flugsvamp.com
Fri Sep 7 21:38:01 GMT 2001

On Fri, Sep 07, 2001 at 07:39:49PM -0700, Andrew Tridgell wrote:
> Personally I don't see a big problem with adding a 3rd which is kqueue
> based. The kqueue design looks quite sane to me and potentially more
> flexible than realtime signals. It also seems to avoid the inherent
> race condition of combining signals with select (which we work around
> in Samba using a rather ugly technique).
> I haven't looked at the oplock/kqueue patch though, so there could be
> ugly stuff under the covers that I don't know about yet.

Arhm.  It doesn't exist just yet.  :-)  I've outlined a proof of concept,
but having only discovered this issue today, haven't written the code.

> Another thing to consider is the directory notification interface that
> we added to Linux at the same time that we added kernel oplock
> (ie. lease) support. See Documentation/dnotify.txt in the Linux kernel
> sources for details, but basically this is another async notification
> system that is needed by Samba and potentially widely applicable to
> other applications. dnotify could easily generate far more events per
> second than leases are likely to so performance issues are more
> important.
> dnotify also uses real time signals in Linux and could potentially use
> kqueue on *BSD. Before deciding if you want to implement real time
> signals you should probably look at dnotify and see if there is
> anything in there that would be troublesome for kqueue.

Actually, not at all.  The kqueue API already handles this quite nicely:

	struct kevent &kev;

	fd = open(".", O_RDONLY);		/* open directory */
	kevent(kq, kev, 1, NULL, 0, &nullts);
Which simply registers an filter on the directory that triggers whenever
the directory (read: file) has been written.  In order to find out what
the exact changes are, you have to call stat() or readdir().

Unfortunately, this is only done on a per-file basis.  There isn't any easy
way to have a inode notify the parent, since in *BSD, there is no 'd_parent'
pointer.  This problem is being worked on.

More information about the samba-technical mailing list