oplocks and file caching

[Jeremy Allison]

Ralph Blach wrote :

> HMMMMMM, the correct length is reported, but the old cached version of
> the file is present.
> Now heres the very intersting point.  If I edit the file, the correct
> version is retrieved.
>
> Any comments??? is this a bug???

Well, this is something that is going to come
up more often now Samba supports oplocks.

The short answer, it isn't a bug in Samba (more
a current technical limitation of user mode CIFS/SMB
support).

The long answer :

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.

What is happening
-----------------

The Windows client opens the file and obtains
an oplock on it. This means the Windows client
believes it has exclusive access to the data
in the file, and will be notified if any other
process attempts to modify the file.

The problem is that this invariant is not true
if you access the file from a UNIX process.

The UNIX kernel doesn't notify Samba when
some other process does a cat (for example)
on the file, so Samba doesn't know that
the file has been accessed from the UNIX
side and therefore cannot break the oplock.

For UNIX'es that have source code available
(Linux, FreeBSD for example) it may be 
possible to modify Samba so that it interacts
with the kernel in the same way that an automounter
does - ie. any traversal into a particular 
inode causes the accessor to be suspended
whilst an up-call into user space is made
to Samba, which can then break the oplock
and ensure a consistant view of the file
for the UNIX process.

Unless the UNIX vendors make such a facility
generally available (Sun have expressed
an interest in doing this) and Samba is extended
to support such a facility then you should
not use oplocks on a share that contains
files being modified both by UNIX processes
and by Windows clients - they will see
inconsistant views of the data.

Network appliance (full disclaimer here, my
wife works for them as their CIFS/SMB Product
Marketing Manager) have solved this problem
in their implementation by causing access by
UNIX/nfs clients to break oplocks granted
to Windows clients, so they can guarentee
a consistant view of the data to both
clients (however, they control the OS
so they can do this easier than the Samba
Team can modify Solaris/IRIX/AIX etc. :-).

Hope this clears up the nature of the 
problem,

Cheers,

	Jeremy Allison,
	Samba Team.


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