Is kernel oplocks = yes a good default?

[Jeremy Allison]

On Wed, Apr 11, 2012 at 03:25:59PM +0200, Christian Ambach wrote:
> I was wondering why Samba servers running on Linux are not giving
> out Level II oplocks by default and thus cause performance
> degradation for certain workloads.
> 
> Digging into that, I discovered that this due to "kernel oplocks"
> set to yes by default and on the two platforms that have kernel
> oplock support code for (Linux and IRIX), level 2 oplocks are not
> supported by the kernel. (OneFS is the only platform that has
> support for them).
> 
> Another bad thing is that kernel oplocks is a global parameter. So
> if an admin is interested in getting NFS/shell interop for just a
> certain share, (s)he cannot turn them off for the other shares to
> get better performance from those.
> 
> I have worked on a patchset that converts the parameter into a share
> option that will allow for more fine-grained configuration.
> Please have a look at it.
> It makes the raw.oplocks test pass when using kernel oplocks = no
> for just the share to be tested.

Looks very good to me. Do you want to include in a 3.6.x release ?

> Additionally, I would like to question the current default value of
> kernel oplocks: we shouldn't cut off our users from the performance
> benefits of level II oplocks on one of our major platforms by
> default.
> 
> I can update the patchset to also flip the default if this is
> considered to be a good idea.

It probably is. The default was set to allow for out-of-the-box
safety for Linux servers exporting the same files by both NFS
and CIFS, but that's probably less used than I thought at the
time, and probably can be expertly set by OEM's who know exactly
what they're doing.

+1 from me (for this patch, and also flipping the default).

Jeremy.