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
Thank you for your help!
To unsubscribe from this list go to the following URL and read the