[Samba] How important are oplocks?

[Jim Morris]

On Wed, 2002-12-18 at 09:52, Bob Puff at NLE wrote:

> If Samba is corrupting the data files, then why wouldn't this be turned OFF by
> default?  I would think data corruption would be a major, MAJOR problem, and
> reduce the usability of Samba.  Is this really true?

It comes down to the fact that Samba is faithfully mimicking a Windows
NT/2000 server.  Windows NT and Windows 2000 servers *BY DEFAULT* also
have OPLOCKS enabled.  Oplocks provide a *SIGNIFICANT* performance boost
for network file operatings when a single user is accessing a file. They
allow the *CLIENT* machine to basically cache the file locally, just
like caching a local file on a local hard drive.  Writes to the file are
cached as well.

Where oplocks cause problems is when a second client wants to open the
same file (as in a shared file database).  Then the Samba/NT/2000 server
must issue what is called an 'oplock break request' to the first client
that has oplocks on the file.  The client is supposed to then flush any
changes to disk, and release the oplocks on the file.  The server must
then wait on this to happen before the second client can be granted
access to the file.

Problems arise when the client takes too long to respond, or fails to
respond to the oplock break request from the server.  The second client
sees a long delay in opening the file.  Furthermore, if file IS opened
by the second client and the first client never responded, or responds
after the timeout occurs, then you can end up with file corruption, as
the first client finally flushes changes to disk, after the second
client has read the now outdated data, and is using it.

Regardless of the problems, the fact of the matter is that if Samba does
not enable oplocks by default, just as Windows NT and 2000 servers do,
then Samba servers yeild much lower performance for many server file
operations performed by the typical Windows network client.  You would
have everyone screaming about how slow the network is, and Samba would
come nowhere near the performance of Windows NT/2000 servers in
benchmarks.

I have been using shared file databases on Windows NT and Windows 2000
servers for years now (dBASE files).  For all customer installs, we
*MUST* disable oplocks on the NT/2000 servers in order to maintain
database integrity.  So this problem is not unique to Samba.  Samba
handles it much more gracefully than NT/2000 do! On NT/2000 servers, you
have to edit a registry key that disables oplocks globally on the entire
server. With Samba, I can disable them on a share or file wildcard
pattern basis, using the 'veto oplock files' option in smb.conf.

The user that compared Samba with/without oplocks to his Netware
server's performance is not comparing apples to apples.  Samba clients
are using the Windows Networking client - and really can only be
compared to a comparably equipped and configured Windows NT/2000
server.  Netware servers require the use of a Netware client package. 
The Netware client has an entirely different implementation of locking
mechanisms, caching algorithms, and the entire network protocol and file
sharing model is different.  As is the Netware server.

I think most experts that have ever researched the topic will agree that
for sheer file serving performance, nothing can beat Netware.
Historically anyway.  I've not seen any benchmarks that included Netware
in a few years.  Where Netware falls down is in 3rd party support (these
days), and the ability to run general purpose applications on your
server.  Plus, the server and client licenses are a LOT more expensive
than a Samba server solution.

I'll hazard a bet that if one were to examine the Netware IPX/SPX
protocol, it is nowhere nearly as convoluted and ad-hoc as the SMB
protocol, which Microsoft hodge-podged together.  You really have to
step back and think about the amount of effort involved by the Samba
Team in faithfully reverse engineering and reproducing all the intricate
details of a protocol that is such a mess!

Keep up the good work, 'Team Samba'!
-- 
/-----------------------------------------------
| Jim Morris  |  Email: Jim at Morris-World.com
|             |    AIM: JFM2001
\-----------------------------------------------