Fixed: OpLocks caused the corruptions/slowness
jim at morris-world.com
Thu Oct 24 01:59:00 GMT 2002
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)
More information about the samba-technical