[Samba] 3.6/SMB2.0 and NT6.0 (Vista/W2K8 not-R2) question

[Stan Hoeppner]

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