[Samba] oplock problems

[Noel Kelly]

A full explanation of oplocks from Jeremy below.  The basic rule seems to be
if a file is static data being shared to many people then oplocks will
increase performace.  If you are dishing out Office documents you had best
turn oplocks off totally.

Oplocks = no 
Kernel Oplocks = no 
Level2 Oplocks = no 

hth 
Noel


Ok, as promised, a brief explaination of oplocks, share modes
and locking.

When a client opens a file it can request an "oplock" or file
lease. This is (to simplify a bit) a guarentee that no one else
has the file open simultaneously. It allows the client to not
send any updates on the file to the server, thus reducing a
network file access to local access (once the file is in
client cache). An "oplock break" is when the server sends
a request to the client to flush all its changes back to
the server, so the file is in a consistent state for other
opens to succeed. If a client fails to respond to this
asynchronous request then the file can be corrupted. Hence
the "turn off oplocks" answer if people are having multi-user
file access problems.

Unless the kernel is "oplock aware" (SGI IRIX and Linux are
the only two UNIXes that are at the moment) then if a local
UNIX process accesses the file simultaneously then Samba
has no way of telling this is occuring, so the guarentee
to the client is broken. This can corrupt the file. Short
answer - it you have UNIX clients accessing the same file
as smbd locally or via NFS and you're not running Linux or
IRIX then turn off oplocks for that file or share.

"Share modes". These are modes of opening a file, that
guarentee an invarient - such as DENY_WRITE - which means
that if any other opens are requested with write access after
this current open has succeeded then they should be denied
with a "sharing violation" error message. Samba handles these
internally inside smbd. UNIX clients accessing the same file
ignore these invarients. Just proving that if you need simultaneous
file access from a Windows and UNIX client you *must* have an
application that is written to lock records correctly on both
sides. Few applications are written like this, and even fewer
are cross platform (UNIX and Windows) so in practice this isn't
much of a problem.

"Locking". This really means "byte range locking" - such as
lock 10 bytes at file offset 24 for write access. This is the
area in which well written UNIX and Windows apps will cooperate.
Windows locks (at least from NT or above) are 64-bit unsigned
offsets. UNIX locks are either 31 bit or 63 bit and are signed
(the top bit is used for the sign). Samba handles these by
first ensuring that all the Windows locks don't conflict (ie.
if other Windows clients have competing locks then just reject
immediately) - this allows us to support 64-bit Windows locks
on 32-bit filesystems. Secondly any locks that are valid are
then mapped onto UNIX fcntl byte range locks. These are the
locks that will be seen by UNIX processes. If there is a conflict
here the lock is rejected.

Note that if a client has an oplock then it "knows" that no
other client can have the file open so usually doesn't bother
to send to lock request to the server - this means once again
if you need to share files between UNIX and Windows processes
either use IRIX or Linux, or turn off oplocks for these
files/shares.

Hope this is clear :-).

Jeremy.


-----Original Message-----
From: c.m.e.reniers at philips.com [mailto:c.m.e.reniers at philips.com]
Sent: 29 October 2002 15:35
To: samba at lists.samba.org
Subject: [Samba] oplock problems



We are running samba 2.2.3a ( for about 3000 users ) on HP/UX 11.11
fileservers. 

Our  customers are complaining about slow response on the opening/closing of
files in office/excel etc. 
In the samba log file we see the following messages : 

[2002/10/29 09:03:27, 0] ../source/smbd/oplock.c:(761) 
  oplock_break: receive_smb timed out after 30 seconds. 
  oplock_break failed for file My Documents/servers.doc (dev = 40220001,
inode = 229991, file_id = 240). 
[2002/10/29 09:03:27, 0] ../source/smbd/oplock.c:(833) 
  oplock_break: client failure in oplock break in file My
Documents/servers.doc 
[2002/10/29 09:03:27, 0] ../source/smbd/reply.c:(4387) 
  reply_lockingX: Error : oplock break from client for fnum = 14026 and no
oploc 
k granted on this file (My Documents/servers.doc). 

We found out that these messages correspond with the slow response that our
users are seeing. 

I've searched the samba archive and there are more people having these
messages. 
The solutions I found were : 
- You may have a netwerk problem ( which is NOT the case in our situation ) 
- Turn oplocks off ( But this may introduce a performance problem ) 

Can somebody please explain : 

- What this message really means. 
- Can it be related to the slow response that our customers are complaining
about 
- Is there a solution to this probem ( our network is ok, turning oplocks
off is not a solution .. ) 

Regards, 

Eddy Reniers,
Philips Research Laboratories
Department Computer Services,  Building WY p 29- postbox WY01
Prof.Holstlaan 4, 5656 AA Eindhoven, The Netherlands

Phone : +31-40-27-44703

Email  : c.m.e.reniers at philips.com

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002