Subject: support for Samba "KERNEL_OPLOCKS"
To: None <email@example.com>
From: Laine Stump <firstname.lastname@example.org>
Date: 02/03/2001 02:14:39
The smb protocol has "oppurtunistic locks" which are set by a client
when it wants to cache a piece of a file; it can then assume that its
cached data is correct until it receives a message from the server
telling it that the lock has been broken. At that time, the client
invalidates that part of its cache, so that new data is retrieved from
the server the next time that part of that file is requested.
Samba's smb implementation can properly implement these locks by using
some sort of IPC (I haven't looked at the details) between the
instances of smbd running on the server. Unfortunately, what it
*can't* do is handle the case of a *different* process on the server
(emacs, vi, etc), or an NFS client, modifying the file.
Irix has implemented a kernel interface that can send messages to
listening applications (via a pipe) when it believes an oplock needs
to be broken due to a modification to a file, and Samba supports this
interface. One of the dos included with Samba claims that Linux and
FreeBSD both have plans to implement this interface. Has there been
any discussion of putting it into NetBSD?
The reason I'm asking about this, is that I spend a lot of time
editing source files on my NetBSD box with emacs, which are then
compiled by (or run on, in the case of perl scripts) a Windows machine
that has the NetBSD box' drive mounted via Samba. I'm constantly
running into situations where the changes I just made to a file with
emacs don't propogate to the Windows machine for several minutes
(because the smbd process isn't aware that the file has changed, so it
doesn't break the oplock to invalidate the client's cache). This is
starting to really annoy me.
Anyone who wants to see the details of what the userlevel code from
this looks like, can get the Samba source and search for
HAVE_KERNEL_OPLOCKS. the file docs/textdocs/File-Cacheing.txt has a
summary of what the problem is and how it's solved.
(I don't normally follow this list (although I searched the archive
for "oplock" first, to see if the topic had been discussed in the
past), so please put me in the Cc list of any replies...)