Hi,
as far as i'm concerned (take this with grain of solt, i'm not a dev,
just mere admin :])
locks - grant exclusive right to access to file for the process
(selfexplainable)
oplocks - if lock is granted, then samba server can grant to client
oplock (opportunity lock) meaning that client (eg windows pc) can cache
the file locally and do the changes to file only locally (which is as
anyone can imagine is multiple times faster), if some other process want
access the same file, oplock is removed and client has to flush cahnges
done locally back to file share
result: leave always on (it is on by def.)
level2 oplocks - allow Windows clients that have an oplock on a file to
downgrade from a read-write oplock to a read-only oplock once a second
client opens the file
result: leave always on (on by def.)
kernel oplocks - this is a way the Linux grants oplocks - and not only
Samba, it is always 'on' by default, it has to be in place, when file
share is accessed from unix, same as from samba (windows)
so eg. if your file share is shared throught unix (NFS) and throught
Samba (Cifs) then linux kernel has to control balance between windows
and unix => kernel oplocks yes always or you face corruption of files
if your file share is accessed only! and exclusively through Samba -
then you can gain considerable speeds gain with 'kernel oplocks = no'
(disabled) (samba doesn't have to wait for kernel to say 'go')
posix locking - similar like kernel oplocks - again, propagate Samba
locks to unix world, so again mandatory when eg. NFS / Samba access to
one share
fake oplocks = can be used on only! on 'r' (read only) file systems,
Samba acts (or better said pretending) like the file is always accessed
by only one process and grants the oplock to anyone who asks for the
file - corruption can not happen, because FS is only *r* this way on 'r'
FS you again gain considerably, as file is always cached locally
example some share with libraries for app:
[lib_v5]
read only = yes
fake oplocks = yes
veto oplock files - this is for files that you dont want to be oplocked,
meaning you dont want them be cached locally on client - example is eg.
placing MS outlook .pst files on netshared FS (which is not supported by
MS in the first place) adn in my experience this causes .pst corruption
if more often, so i use it like:
[home]
path = /home/%U
veto oplock files = /*.PST/*.pst/
As resume, in my scenario i left most on default, because my shares are
accessed by NFS and Samba at same time.
Yours might be different, so to disable kernel oplocks and posix locks
might be an option. I dont see any benefit in disabling oplocks or
level2 oplocks generally for all files (i disabled them for .pst files
because they're like database files and caching is not good for it).
hope this helps,
Karel
On 10/15/2014 03:07 PM, Ray Van Dolson wrote:
On Wed, Oct 15, 2014 at 08:50:06AM +0000, Werf, C.G. van der (Carel) wrote:
Hi All,
We are in the process of transfering our fileservers to a new
OS-version.
Installed latest OS 6.5 and the current Samba3-version, which is
Samba 3.6.9. Data folders are on XFS filesystem. Data folders are
exported as NFS3-shares to an SSL-login server
Data folders are exported as Samba-shares to several different
clients: - windows7, ubuntu, SL6x, MacOSX
Now it seems that some of the windows7-clients see files as being
read-only because they seem to be locked. I've read a lot of
different info about file locking in Samba, but information seems
very confusing.
So,my question is, considering the environment of mixed clients over
CIFS and NFS, what is the preferable Samba-setting for locks,
Kernel_oplocks, Oplocks etc ?
If anyone has a lot of samba experience, please share your thoughts
on this subject.
Regards,
Carel van der Werf
This has been discussed a few times on the Samba mailing list.
My recommendations are to disable oplocks and level2 oplocks explicitly
at the global level.
In some cases you'll want to disable posix locks at the share level.
Ray
