Very bad performance when copying large files from windows to samba-share

[Esh, Andrew]

If this were me (and most of you are probably glad it is not), I'd synch the
clocks, start Samba at log level 10 (unlimited log size), mount the share
from Windows, and let it sit for a few minutes. This will allow Samba to sit
with the user authenticated for a while, which makes a better log. I'd run
Ethereal (www.ethereal.com) on the Windows side, unfiltered. Then I'd start
the smaller (good) transfer, and note the time. Wait until the transfer
ends, and record the time again. Save the capture file from Ethereal, and
start a new capture. Repeat for the larger (bad) transfer. Save another
capture.

That that point, all the information needed to find the point in the code at
which Samba is sitting while the pause is happening. Look for large gaps in
the packet flow. Find out what Samba's log says during that time period.
Determining where the gaps are occurring will help us understand why.
Compare and contrast the good session with the bad session. Is there a
timeout message at the same point in the bad session, that the good transfer
instead began to send data?

It was long sessions like this that found the exact recipe for Win98 rabbit
pellets. (Unfortunately, we also found that there was nothing we could do to
Samba to get Windows to run faster. :)

I think the same thing will work here.

-----Original Message-----
From: Lars Heineken [mailto:Lars.Heineken at gmx.de]
Sent: Friday, April 12, 2002 3:22 PM
To: samba-technical at lists.samba.org
Cc: don_mccall at hp.com
Subject: Re: Very bad performance when copying large files from windows
to samba-share




On Fri, 12 Apr 2002 12:58:54 -0700
"MCCALL,DON (HP-USA,ex1)" <don_mccall at hp.com> wrote:

> The fact that you have disk activity with no network activity
> on the samba server when you try to transfer, and the timeout
> issue, almost sounds like you have the 'strict allocate' flag
> for smb.conf set true - this would force samba to actually write
> bogus data to fill up a file on your disk of the size that you are
> about to transfer, and if it were really big, or disk writes really
> slow, could be causing you to time out... check testparm output for 
> 'strict allocate' and see what the value is - it SHOULD default to 
> no, or false, but maybe your distribution changed the default on you?
> Just a guess,
> Don

The testparm showed that the setting is no. T be shure, I set it to "no"
manually but the behavoir hasn't changed. 
This is a nasty one, your mail could have been the solution, as your
description of the behaviour was quite what happens here. Maybe there's a
way to check the network traffic if win98 initiates a transfer with a strict
allocate ?
-------------- next part --------------
HTML attachment scrubbed and removed