NT & Win98 slow copies
Stephen L Arnold
arnold.steve at ensco.com
Wed Aug 12 17:01:13 GMT 1998
Howdy all:
For those who are curious (eg, Peter de Groot
<pdgtech at wantree.com.au>) here are the (I think) relevant posts
from recent samba digests concerning win98 and or NT performance
problems copying files between local drives and samba shares. It
looks like there should be some new options to play with in the
next samba release. Could Jeremy or Andrew confirm?
(BTW, nice "virtual" interview in Linux Journal a couple issues
back; it was good for a few hearty chuckles, and *very* informative)
When the world was young, various folks carved some runes like this:
> Date: Mon, 27 Jul 1998 10:13:59 -0700
> From: Jeremy Allison <jallison at cthulhu.engr.sgi.com>
> To: tl at fairplay.no, "samba at samba.anu.edu.au"
> Subject: Re: Slowdown when copying large files (PR#8624)
>
> tl at fairplay.no wrote:
>
> > Hmm, I missed the original post, but this sounds like be the
> > it could bug I reported 15 days ago to samba-bugs (PR#8316)
> > and still haven't got any responses to.
>
> Sorry, I'm still integrating incoming patches.
>
> > If it's the same bug it's mainly the write performance
> > that's bad, and in reality the performance is worse
> > than Win95/WinNT for all files, it's just get worse
> > for large files (exactly how much depends on the OS).
> > To check if it's the same problem turn up the debug-level
> > to 3, and copy a moderately large file to the Samba
> > server from the local disk of a Win98 workstation.
> > If you get *lots* of SMBwrite and SMBflush in the
> > log-file you have the same problem.
> >
> > A "good" log created from WinNT features one (or
> > sometimes two) SMBwrite per ~63k and zero SMBflush.
> > A log from a Win98 machine features one or two SMBwrite
> > per 1.5k (!) and one SMBflush per 1.5k!!!
> >
> > Anything above ONE SMBflush per file (at the end)
> > or one SMBwrite per 10k or so indicates a serious problem.
> >
> > A stop-gap measurement to get *usable* performance is
> > recompile with 'NO_FSYNC' defined (or the fsync() call
> > in server.c:sync_file() commented).
>
> This is what I'm going to do for 1.9.18p9, but I will
> parameterize it.
>
> > This removes the silly 'wait until everything is on
> > disk before continuing at every 1.5k', but doesn't
> > fix the small block-size used. The small block-size
> > used still limits the performance, but it's actually
> > usable for larges files.
> >
> > If you can confirm that this is what happens to you
> > too it might be time to send it to 'samba-urgent',
> > as it's likely to affect LOTS of people as more and
> > more people start using Win98.
>
> Well the problem is the small block size used is *client*
> defined - not server. My guess is that the Win98 explorer
> is optimised for Web performance, (ie. doing MSS size
> reads/writes) and as the same binary is used for both SMB
> file browsing and Web browsing the silly block size has been
> used throughout.
>
> Does anyone know if there is a Win98 registry setting to
> set the SMB read/write size ?
>
> Jeremy Allison,
> Samba Team.
> --
And like this:
> From: Andrew Tridgell <samba-bugs at samba.anu.edu.au>
> To: anthonm at tams.com.au
> Subject: Re: Slowdown when copying large files (PR#8617)
> Message-ID: <19980726144101Z12610895-18748+1357 at samba.anu.edu.au>
>
> > Further to my previous post, I have made an interesting
> > discovery. This particular slowdown only occurs from
> > clients that are running Windows 98.
>
> The Windows98 explorer (and possibly other programs)
> incorrectly set the "sync" bit in write requests to
> network shares. This causes an enormous slowdown as
> Samba (quite correctly) does a fsync() on the file after
> each write. Combine this with the fact that Windows98
> explorer uses very small write sizes (around 1.5k) and
> you get really terrible results.
>
> The only way to work around this at present is to add:
>
> #define NO_FSYNC 1
>
> in local.h and recompile Samba. This should give you
> an enormous speedup. In one test I did tonight a speedup
> of a factor of 15 was observed.
>
> As I have not yet witnessed a Windows program using the
> fsync bit correctly (they all seem to treat it like flush,
> which is a quite different thing!) you don't actually lose
> anything by doing this. The sync is only useful for
> transactional systems where a particular state of a file
> needs to be guaranteed in the case of a server crash.
> I suspect what these programs really want is a flush,
> which Samba does implicitly on every write anyway.
>
> I have raised the possibility of adding a runtime config
> option to disable fsync on the samba-technical list.
>
> Cheers, Tridge
Later, we had this excahnge:
> Date: Tue, 28 Jul 1998 16:12:40 +0100
> From: Matt JD Aldridge <Matt.Aldridge at NEXOR.Co.UK>
> To: samba <samba at samba.anu.edu.au>
> Subject: Re: Slowdown when copying large files (PR#8617)
> Message-ID: <000c01bdba3a$2a0dd120$5309f380 at firefox.nexor.co.uk>
>
> > Date: Mon, 27 Jul 1998 10:09:30 -0700
> > From: Jeremy Allison <jallison at cthulhu.engr.sgi.com>
> > To: peloy at ven.ra.rockwell.com, "samba at samba.anu.edu.au"
> > <samba at samba.anu.edu.au>
> > Subject: Re: Slowdown when copying large files (PR#8617)
> > Message-ID: <35BCB44A.49535E32 at engr.sgi.com>
> >
> > peloy at ven.ra.rockwell.com wrote:
> > >
> > > Andrew Tridgell <samba-bugs at samba.anu.edu.au> wrote:
> > >
> > > > The Windows98 explorer (and possibly other programs)
> > > > incorrectly set the "sync" bit in write requests
> > > > to network shares. This causes an enormous
> > > > slowdown as Samba (quite correctly) does
> > > > a fsync() on the file after each write.
> > > >Combine this with the fact that Windows98
> > > > explorer uses very small write sizes (around 1.5k)
> > > > and you get really terrible results.
> > >
> > > Andrew, but if it is Windows 98 the one that is
> > > screwing things up, wouldn't this slowdown be
> > > seen when the server is something else, like
> > > Windows 95/NT, etc.?
> >
> > Apparently not - according to one of JohnT's technical
> > contacts at MS - doing a fsync on a file in NT isn't the
> > same as a UNIX fsync, but only *schedules the write to
> > be done* !
> >
> > I will add this option before 1.9.18p9 ships - the only
> > question is - should it be on or off by default ?
>
> Is there no way to identify the client as being Win 98
> and act appropriately? Shame if not.
>
> Cheers, Matt.
****************************************************************
Stephen L. Arnold Systems Engineer
ENSCO Inc. email: arnold.steve at ensco.com
P.O. Box 5488 www: http://www.ensco.com
Vandenberg AFB, CA 93437 voice: 805.734.8232 x68838
fax: 805.734.4779
#include <std_disclaimer.h>
****************************************************************
More information about the samba
mailing list