SCIENTIFIC-LINUX-USERS Archives

October 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Karel Lang AFD <[log in to unmask]>
Reply To:
Karel Lang AFD <[log in to unmask]>
Date:
Wed, 15 Oct 2014 17:32:12 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (107 lines)
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
>

ATOM RSS1 RSS2