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

Esh, Andrew AEsh at
Fri Apr 12 14:39:02 GMT 2002

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 ( 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

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]
Sent: Friday, April 12, 2002 3:22 PM
To: samba-technical at
Cc: don_mccall at
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> 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

More information about the samba-technical mailing list