[Samba] How important are oplocks?
Marian Mlcoch, Ing
mm at tsmp.sk
Thu Dec 19 09:58:00 GMT 2002
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
> > default? I would think data corruption would be a major, MAJOR problem,
> > 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
> 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
More information about the samba