oplocks and file caching

Jeremy Allison jallison at whistle.com
Fri Jan 30 17:43:35 GMT 1998

David Collier-Brown wrote:
>   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.

Well the problem is none of these approaches will
work with arbitary UNIX processes (unless you want
to GPL solaris & we can modify it :-).

In order to get complete consistancy between Samba
oplocks and arbitrary UNIX process we *need* kernel
support - we have to cause an arbitary open() to
block until we have broken the oplock.

The correct place for oplocks is really in the
kernel - with the method used by Samba as a
backup for systems that don't support this.

Alternatively, an easier method (rather than
putting the entire oplock semantics in the
kernel) is to have a POSIX defined method 
of getting an upcall (some message - maybe a
pipe into the kernel - that's what autofs on
Linux uses) when someone wants to open a file 
you have flagged (probably via a fcntl) as 
'oplocked'. Samba can then handle the break 
semantics as it does now.

If Sun want to discuss this I'd be more than
happy to work with you on this (I've already
raised the issue and had a brief meeting with
a Solaris kernel engineer, but nothing more
came of it).


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba mailing list