[Samba]DOS app won't run off a Samba drive!

[Glenn Scherb]

Enabled oplocks can also cause problems with some virus scanners.  I
found that McAffee running off a Windows client left all the files it
scanned open if oplocks are enabled.  Eventually the server ran out of
file handles and came to a screeching halt.

My general practice has been to disable them for all shares to reduce
corruption in Access databases and Outlook *.pst files. Performance
doesn't really seem much slower as a result.

Regards,
Glenn Scherb

-----Original Message-----
From: samba-admin at lists.samba.org [mailto:samba-admin at lists.samba.org]
On Behalf Of Rashkae
Sent: Tuesday, January 29, 2002 11:38 AM
To: Greg Conway
Cc: Samba
Subject: RE: [Samba]DOS app won't run off a Samba drive!


I will try to explain my limited understanding. Others can correct me
and fill in the blanks as we go. :)

Oplocks stand for Opportunistic Locking.

Here's how it works.

Client requests to open a file from the server. If no other clients are
using that particular file, the server will grant the client an
"opportunistic lock".  This means that the client will cache a copy of
the file in local memory.  That way, read/write operations to the file
don't have to go over the network.  This is, of course, a significant
performance boost. The server will not allow other clients to open the
file, since the client local cached copy and the server copy are likely
to be out of sync.

The fun begins when a second client wants to open a file that is
oplocked. The server must inform the original client that the lock will
be broken. At this point, Client 1 is supposed to upload any changes to
the file back to the server and continue on the way things would
normally work. All read/write operations are performed over the network.
Databases should lock on a record by record basis for write operations
(Thereby being safe for multiple users.)

If client 1 does not co-operate with the break request, the server has
to force a break. The file to client 1 is closed in whatever state the
cache was last synchronized with the server.

For oplock granting and breaking to work properly requires handshaking
between client user software, client os, server software, and server os.
All possible combinations of the above have their own special quirks and
behavior. (Note: it is only in recent versions of Linux Kernel that
Linux OS participates in the matrix. This is where the kernel oplocks
comes into play. If kernel oplocks are not enabled, linux will not know
that a file in a samba share is 'locked', and will allow local linux
users or NFS users to open the file without negotiating a break with the
SMB client. Chaos ensues. On the other hand, if Unix processes other
than Samba will not be opening the files for write, disabling kernel
oplocks removes yet another possible source of problems, the server os.)

Long ago when I was young and innocent, and administering NT 4 servers
for a living, I worked out the rule of thumb of always disabling Oplocks
whenever a database was involved. (In Windows, this can be done with a
registry key, but it affects the whole system. Oplocks cannot be
disabled on a file by file or share by share basis.) You can avoid much
database corruption this way. *Especially* Dos Databases, since older
DOS software was not "opportunistic lock aware" (quote from MS tech
support.)


Another neat trick Samba has is the ability to "fake oplocks". This will
make samba always grant oplocks, to multiple simultaneous clients. This
can be a boost to read-only shares, since the files will never be
changed, it doesn't matter if all the clients and server are in sync.
The problem with this, of course, is that no one can modify the file
while SMB clients are using it. Otherwise, chaos ensues. :). This is
probably only safe on CD-ROM shares.

Oh, BTW, Samba enables oplocks by default.

Personally, I am not a fan of performance over stability 'features.',
but that's just MNSHO. I am not a coder or engineer, and probably
misunderstand many of the concepts involved. I'm just the person who has
to explain to clients why their database is hosed and the previous 2
weeks of tape backups are no good because nobody rotated the tapes and
the one in the drive went bad long time ago.





On Tue, 29 Jan 2002, Greg Conway wrote:

Hi Rashkae,

Well, all these "oplocks" are a little new to me!

I have been running off the same smb.conf for the last six or seven
machines, and this is the first time I have encountered problems since I
spent a long time writing that original smb.conf!

So do I presume...

you can put a "oplocks" section in the [global] section, to enable
oplocks - are they enabled by default? is this why I have never heard of
them before?

you can then put a "veto oplocks" section into individual shares ie
[data], to remove oplocks from that particular share.

Sorry to be thick, can somebody please explain to me in windows-users
terms
:) exactly what oplocks does? It is similar to SHARE.EXE? Why do my
Win2k machines work be default but not my Win98 machines?

Anyway, just interested in the hows and whys rather than blindly fixing
things and not knowing how I did it!!

Regards,

Greg.

> -----Original Message-----
> From: Rashkae [mailto:rashkae at wealthmap.ca]
> Sent: 29 January 2002 14:33
> To: Dragos
> Cc: Greg Conway; Samba
> Subject: Re: [Samba]DOS app won't run off a Samba drive!
>
>
> Why not just disable openlocks entirely? Makes allot of sense to me 
> for  a server that primarily dishes out multi-user files, oplocks at 
> best is a performance hindrance, at worst a dangerous database 
> corrupting monster.
>
> (I think your able to disable oplocks on a share by share basis, if 
> you have other shares where oplocks would be useful.)
>
> On Tue, 29 Jan 2002, Dragos wrote:
>
> glad to hear that it works...:)
> however, keep the 'veto oplocks files' option handy, because when 
> you'll have more than one connection to the share (multiple win 
> clients working on the
> database) things will slow down.
>
> dragos

***********************************************************************
This is a confidential communication between sender and addressee. If
you are not the intended recipient of this message, please notify the
sender and do not read, copy, use or disclose this communication to
others. Any opinions or views expressed are those of the individual, and
unless otherwise stated, are not those of the company. All attachments
and intellectual rights remain the property of GML (NT) Limited.
***********************************************************************



-- 
To unsubscribe from this list go to the following URL and read the
instructions:  http://lists.samba.org/mailman/listinfo/samba