oplocks and file caching

David Collier-Brown davecb at Canada.Sun.COM
Fri Jan 30 15:38:56 GMT 1998

Ralph Blach <rcblach at raleigh.ibm.com> asked about oplocks and caching,
and Jeremy Allison <jallison at whistle.com> replied:

> Short of modifying the underlying UNIX kernel
> for every operating system that Samba runs on,
> there is no way to ensure that access to a file
> from a UNIX process sees the same data as access
> to a file from the Windows client that has
> oplocked the file.

  There are three ``traditional'' approaches to detecting and managing
concurrent access to files on unix...

	0: don't.
	1: use file/inode times
	2: use locks

  0 is the normal one, which was frustrating to my colleagues in
a previous life, because we couldn't segregate our data into
sets that were never accessed except by out applications...

  So we implemented a form of opportunistic locking for our own
files (which were the 90% case), with heuristics built in
for the others.
  Heuristic #1 was implemented by storing a date in the ``lock''
variable for a file.  The date was the file date when we
established the lock.  If we detected an unexpected date change 
on a close or fflush, we did the usual
	``someone else is editing your file''
shtick in our application, and made or broke the oplocks
depending on the user's reply.  In the non-interactive apps,
which were more common, we just broke the locks and let the
apps recover and roll forward.
  I suspect this is close to the PC behaviour: the author
modelled it on MS locking (:-))

  On some architectures we actually called flock(fd,LOCK_SH|LOCK_NB) and
LOCK_EX as part of the process, but the latency cost performance on
a few older machines.  Modern OSs were ok.

  Methinks a date check might be useful if it can be done with
limited performance impacts.
  The risk is that you might need to check file dates far too
often, thus causing repeated rereading of the inode.  See various
white papers on nfs and cachefs for hints at what people have 
found in practice...

David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | davecb at hobbes.ss.org, canada.sun.com
M2N 1Y3. 416-223-8968 | http://java.science.yorku.ca/~davecb

More information about the samba mailing list