Fixed: OpLocks caused the corruptions/slowness

[Jim Morris]

Jay Ts <jay at jayts.cx> wrote on Wed, 23 Oct 2002 16:03:41 -0700:

> Aside from that, I welcome any comments on the above excerpt.
> It was suggested by David Collier-Brown, my co-author, and
> he had to explain it carefully to me before I wrote about it.
> Any suggestions for improving the discussion are welcome!

Well, I will comment on my experience with Oplocks. In general, I have 
found in production environments that oplocks cause major performance 
issues on ANY SMB file server when serving up database files.  This is 
true any time more than one client will be accessing the file(s) 
involved, and the files involved do not have to be huge. Database type 
does not seem to matter either - I've seen oplock related performance 
issues with dBase, Access, Paradox and other proprietary table types.

I remember one instance with a DOS-based database application with files 
that were just a few MB's in size. If 'veto oplocks' was not set for 
those files, performance of certain operations was degraded by an order 
of ten or more.  Reports that ran in 30 seconds might take 5 to 10 
minutes to complete for example.

The problem is not unique to Samba - it occurs with Windows NT and 
Windows 2000 servers as well, and with both DOS and Windows client 
systems.  I work with a retail point-of-sale application which runs on 
DOS and Windows clients - with the fileserver typically running on 
Windows NT.  We have ALWAYS had to disable oplocks on the NT servers. 
It's a lot easier to turn them off on Samba than it is with NT too! With 
NT, its a global setting in the registry, so you disable them for the 
server. At least with Samba it can be file specific.

Anyway, I think you summarized the cause of the issue quite nicely. 
Namely, the degradation occurs when a second client attempts to open a 
file that has outstanding oplocks on it. The server issues an oplock 
break request to the first client. Until the client with the oplocks 
honors the break request, the second client does not open the file.  The 
rub is that there are many clients (older Windows versions for example) 
that do not seem to properly honor the oplock break requests from Samba. 
So what ends up happening is a timeout sitation in Samba must then occur 
before the oplocks are forcibly broken, and the second client allowed to 
open the file.

Someone feel free to correct me if my understanding is incorrect on this 
matter....  its been a couple of years since I looked at the source 
involved.  I am mainly commented based on what I have seen in Samba log 
files over the years.


--
Jim Morris (Jim at Morris-World.com)