Tags Tags

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

August 23rd, 2011 - 12:40 pm ET by starlight | Report spam
Help Create a new topic
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!

To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
email Follow the discussionReplies 3 repliesReplies Make a reply

Similar topics

Replies

#1 Jeremy Allison
August 23rd, 2011 - 02:50 pm ET | Report spam
On Tue, Aug 23, 2011 at 12:27:19PM -0400, 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.
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Replies Reply to this message
#2 Stan Hoeppner
August 23rd, 2011 - 02:50 pm ET | Report spam
On 8/23/2011 11:27 AM, 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
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Replies Reply to this message
#3 starlight
August 23rd, 2011 - 04:00 pm ET | Report spam
At 11:41 AM 8/23/2011 -0700, Jeremy Allison wrote:
On Tue, Aug 23, 2011 at 12:27:19PM -0400, wrote:
>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.



But apparently not with sufficient aggression. No
doubt whatsoever that files are being read over
and over again--clear as day in the network
statistics. I'll guess that Windows is dropping
the cached copy of network files immediately once
the are closed.

So it's really a question about the Windows client
side, which makes me think that SMB2 vs SMB1 will
make little difference for the NT6.0 kernel. The
MS announcement does focus on improvements in
the NT6.1 kernel with SMB2.1, so I'll have to
try that at some point.

http://technet.microsoft.com/en-us/...10%29.aspx

Thank you for your reply.

To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search