[Samba] How important are oplocks?

[Marian Mlcoch, Ing]

Thanks Jim for best report of oplock as i read.
Super can be if you can add info or link about list of dangerous database
engines for oplocks...
Btw.  Foxpro 2.6 = is ok.
          Foxpro 7.. = bad.
          Clipper    =  dangerous...
exist this list for off oplocks?



----- Original Message -----
From: "Jim Morris" <jim at morris-world.com>
To: "Bob Puff at NLE" <bob at nleaudio.com>
Cc: "Jean-Paul ARGUDO" <jean.paul.argudo at pack-solutions.com>; "Joel Hammer"
<Joel at HammersHome.com>; <samba at lists.samba.org>
Sent: Wednesday, December 18, 2002 6:02 PM
Subject: Re: [Samba] How important are oplocks?


> 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
> \-----------------------------------------------
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba