On Sun, 2003-07-27 at 22:40, Bret Hughes wrote:
> > > > I did exactly that a couple of days ago and found that I needed to add
> > > >
> > > > kernel oplocks = no
> > > >
> > > > in /etc/samba/smb.conf. Once I did that the errors stopped.
> > >
> > > Isn't there a significant performance hit for certain situations by not
> > > using the oplocks?
> >
> > This is best answered by the manpage entries for "fake oplocks" and
> > "oplocks"...
> >
> > - fake oplocks (S)
> > Oplocks are the way that SMB clients get permission from a
> > server to locally cache file operations. If a server grants an oplock
> > (opportunistic lock) then the client is free to assume that it is the
> > only one accessing the file and it will aggressively cache file data.
> > With some oplock types the client may even cache file open/close
> > operations. This can give enormous performance benefits.
> >
> > When you set fake oplocks = yes, smbd(8) will always grant oplock
> > requests no matter how many clients are using the file.
> >
> > It is generally much better to use the real oplocks support rather than
> > this parameter.
> >
> > - kernel oplocks (G)
> > For UNIXes that support kernel based oplocks (currently
> > only IRIX and the Linux 2.4 kernel), this parameter allows the use of
> > them to be turned on or off.
> >
> > Kernel oplocks support allows Samba oplocks to be broken whenever a
> > local UNIX process or NFS operation accesses a file that smbd(8) has
> > oplocked. This allows complete data consistency between SMB/CIFS, NFS
> > and local file access (and is a very cool feature :-).
> >
> > This parameter defaults to on, but is translated to a no-op on systems
> > that no not have the necessary kernel support. You should never need to
> > touch this parameter.
> >
>
> Yes That is what I remembered. So really the issue is that there may be
> a data consistency if fake oplocks are used and perfomance hit if not.
> Does this sound right?
This is a little more descriptive, taken from the O'Reilly samba book:
- fake oplocks
If set, returns YES whenever a client asks if it can lock a file and
cache it locally but does not enforce the lock on the server. Results
in performance improvement for read-only shares. NEVER USE WITH
READ/WRITE SHARES!
- oplocks
If YES, supports local caching of oplocked files on the client. This
option is recommended because it improves performance by about 30%.
Short story, I'd leave well enough alone. It doesn't hurt anything by
having it, and disabling it just to avoid the log entries will seriously
degrade performance. Of course, YMMV. ;-)
--
Jason Dixon, RHCE
DixonGroup Consulting
http://www.dixongroup.net
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
