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:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 3:22 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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)" <[EMAIL PROTECTED]> 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 ?
