samba - Aug 2011 - 3.6/SMB2.0 and NT6.0 (Vista/W2K8 not-R2) question

Hello Samba Team,

Have a W2K8 not-R2 (NT6.0) server that compiles code
served from a CentOS 5.6 server running Samba 3.5.5
over an Infiniband link.

Works nice but an 'imake' step that grinds through
every source file several times takes ten-to-twenty
times longer than when it runs locally on the Linux side.

It's apparent that the entire source tree is cached
in memory by Linux, but that the Windows side retrieves
every file over-and-over again, a process that uses
more CPU than anything else so that's the bottleneck.

Windows oplocks seems like the answer to improving
performance as it would allow the Windows server
to cache the files as well.
>From the MS documentation, it appears there might be some
oplock support in their SMB 2.0 client.  Is this the case?
Any chance that oplock-based caching of files that are
only read will happen on the Windows side if we install
Samba 3.6 and enable SMB2?

Also, we disable kernel oplocks in Samba because the
Linux kernel fakes the NFS-visible modification timestamp
of files that Samba oplocks for the duration that the
locks are held.  This causes spurious rebuilds by
Linux and Unix NFS clients when the code is rebuilt
at the same time.

Does setting "kernel oplocks = no" in Samba 3.6 interact
with the SMB2 oplock feature?  I.E. does it disable
SMB2 oplocks?

Thank you for your help!

On 8/23/2011 11:27 AM, starlight at binnacle.cx wrote:
> Hello Samba Team,
> 
> Have a W2K8 not-R2 (NT6.0) server that compiles code
> served from a CentOS 5.6 server running Samba 3.5.5
> over an Infiniband link.
> 
> Works nice but an 'imake' step that grinds through
> every source file several times takes ten-to-twenty
> times longer than when it runs locally on the Linux side.
> 
> It's apparent that the entire source tree is cached
> in memory by Linux, but that the Windows side retrieves
> every file over-and-over again, a process that uses
> more CPU than anything else so that's the bottleneck.
> 
> Windows oplocks seems like the answer to improving
> performance as it would allow the Windows server
> to cache the files as well.
> 
> From the MS documentation, it appears there might be some
> oplock support in their SMB 2.0 client.  Is this the case?
> Any chance that oplock-based caching of files that are
> only read will happen on the Windows side if we install
> Samba 3.6 and enable SMB2?
> 
> Also, we disable kernel oplocks in Samba because the
> Linux kernel fakes the NFS-visible modification timestamp
> of files that Samba oplocks for the duration that the
> locks are held.  This causes spurious rebuilds by
> Linux and Unix NFS clients when the code is rebuilt
> at the same time.
> 
> Does setting "kernel oplocks = no" in Samba 3.6 interact
> with the SMB2 oplock feature?  I.E. does it disable
> SMB2 oplocks?
If these client machines have enough excess RAM to cache the entire tree
and execute builds, why aren't you instead simply copying the tree files
from the server to a local RAM disk, building, then pushing the result
files back to the server?

Massaging your current scripts to do this should be trivial.  You'll get
fully consistent run times to boot.  Sure, it's not as 'convenient'
as a
remote shared filesystem acting like a local non-shared one, but then
again they never really have, and never will, fully act as such.  WRT
convenience, once the scripts are rewritten it's a non issue.

-- 
Stan

On Tue, Aug 23, 2011 at 12:27:19PM -0400, starlight at binnacle.cx
wrote:
> Hello Samba Team,
> 
> Have a W2K8 not-R2 (NT6.0) server that compiles code
> served from a CentOS 5.6 server running Samba 3.5.5
> over an Infiniband link.
> 
> Works nice but an 'imake' step that grinds through
> every source file several times takes ten-to-twenty
> times longer than when it runs locally on the Linux side.
> 
> It's apparent that the entire source tree is cached
> in memory by Linux, but that the Windows side retrieves
> every file over-and-over again, a process that uses
> more CPU than anything else so that's the bottleneck.
> 
> Windows oplocks seems like the answer to improving
> performance as it would allow the Windows server
> to cache the files as well.
> 
> >From the MS documentation, it appears there might be some
> oplock support in their SMB 2.0 client.  Is this the case?
> Any chance that oplock-based caching of files that are
> only read will happen on the Windows side if we install
> Samba 3.6 and enable SMB2?
oplocks are supported in MS's default SMB1 client.
You don't need SMB2 for that. The Windows client should
already be using oplocks.
> Also, we disable kernel oplocks in Samba because the
> Linux kernel fakes the NFS-visible modification timestamp
> of files that Samba oplocks for the duration that the
> locks are held.  This causes spurious rebuilds by
> Linux and Unix NFS clients when the code is rebuilt
> at the same time.
> 
> Does setting "kernel oplocks = no" in Samba 3.6 interact
> with the SMB2 oplock feature?  I.E. does it disable
> SMB2 oplocks?
It disables mapping the SMB1/SMB2 oplocks to Liux
kernel leases.

Jeremy.