On Sun, 2003-07-27 at 21:11, Jason Dixon wrote: > On Sun, 2003-07-27 at 21:36, Bret Hughes wrote: > > On Sun, 2003-07-27 at 20:19, Gerry Doris wrote: > > > > There's a kernel oplock setting in samba you can change. I don't have > > > > time to go into it now, but paste your error message into google, it > > > > will give you a heap of references to it. > > > > > > > > Regards, > > > > Ed. > > > > > > 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? Bret -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
