Howdy all: For those who are curious (eg, Peter de Groot <pdgtech@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@cthulhu.engr.sgi.com> > To: tl@fairplay.no, "samba@samba.anu.edu.au" > Subject: Re: Slowdown when copying large files (PR#8624) > > tl@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@samba.anu.edu.au> > To: anthonm@tams.com.au > Subject: Re: Slowdown when copying large files (PR#8617) > Message-ID: <19980726144101Z12610895-18748+1357@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, TridgeLater, we had this excahnge:> Date: Tue, 28 Jul 1998 16:12:40 +0100 > From: Matt JD Aldridge <Matt.Aldridge@NEXOR.Co.UK> > To: samba <samba@samba.anu.edu.au> > Subject: Re: Slowdown when copying large files (PR#8617) > Message-ID: <000c01bdba3a$2a0dd120$5309f380@firefox.nexor.co.uk> > > > Date: Mon, 27 Jul 1998 10:09:30 -0700 > > From: Jeremy Allison <jallison@cthulhu.engr.sgi.com> > > To: peloy@ven.ra.rockwell.com, "samba@samba.anu.edu.au" > > <samba@samba.anu.edu.au> > > Subject: Re: Slowdown when copying large files (PR#8617) > > Message-ID: <35BCB44A.49535E32@engr.sgi.com> > > > > peloy@ven.ra.rockwell.com wrote: > > > > > > Andrew Tridgell <samba-bugs@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@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> ****************************************************************
Chong Shang Shan
1998-Aug-13 01:47 UTC
Living with WinNT servers / password synchronization
Hello, I am running samba 1.9.18p8-1 on a Debian Linux machine. This machine is set to be a local master and domain master and logons, serving 10 Win95 machines via the LAN. There are *many* WinNT servers "out there", not maintained by me, which I have no interest in communicating with, except to live peacefully with them, and not step on their toes. Everything works perfectly except that the samba daemon keeps writing gobfuls of messages like NET: 130 messages suppressed. 137.132.80.131 sent an invalid ICMP error to a broadcast 137.132.80.124 sent an invalid ICMP error to a broadcast 137.132.80.132 sent an invalid ICMP error to a broadcast The IPs apparently all come from Win NT servers. What is wrong with my configuration, and how can I solve it? (other than pipe the messages to /dev/null?) Another thing worries me is the possibility of unsynchronized passwords. Apparently, samba allows users to change their passwords via the Win95 control panel. But the network logon password seems to be different from the "Windows password". As long a user changes his password using the control panel on one machine, everything seems ok. But a changed password might not be propagated to the "Windows password" of another machine, and subsequent changes of passwords will give "password not changed" messages, even when the network password _is_ changed (pure confusion). So far, I have not informed my users of this facility, and with this bug, I'm not sure if I should. But it is a real pain to make everyone change their passwords through the root. :) css. -- Chong Shang Shan <*> ChongSS@letterbox.com <*> == Standard disclaimer applies ===========================================
There is a bug in the Microsoft LanManger implementation which mismaps
long filenames for 16-bit applications - thus 16-bit apps run from
long path names on networked shares will often fail. Try sharing the
apps from the same pathname on a Win95 client and running them under
NT - I suspect the same thing will happen. Workaround: don't use long
filenames.
Matt
> > I have a strange situation. I have a Linux machine running samba
> > 1.9.18p8, serving a mix of NT Workstation 4.0 and Windows 95 clients.
> In
> > general, things have worked flawlessly, with one exception: none of
the
> > clients are able to execute programs stored on these shares. Full
> reading
> > and writing to the shares is possible; and even though I cannot see
how
> it
> > would be relevant, the execute bits are set to all files. I can
provide
> > needed portions of my smb.conf file as needed. Any suggestions or
> > comments are most welcome.
>
> I have noticed it can depend on the share name or maybe the name of
> the directory it is in
>
> For example I have the two following shares...
>
> 1.) General
>
> 2.) StaffShare
> folders under this share have names like
> Alex_Ardalich
>
> If I put an app in 'Alex_Ardalich' I get something like a file not
> found errors.
>
> An app in a folder under the General share runs fine.
>
> Alex
--
Matt Chapman
E-mail: mattyc@cyberdude.com
> Hello All: > I use samba mostly for printing. On NT server you can install the necessary > print drivers for 95, NT, etc so that when a user connects to a printer it > automatically downloads the correct driver. Is there anyway to do this with > samba? > > Eric > > Eric Gurevitz > gurevitz@cs.umd.edu > PC Support > Computer Science > University of Maryland > 301-405-2749In my experience NT will add the correct driver as long as you have "printer driver " set correctly in smb.conf ('man smb.conf' for more info). For information on how to set up Samba so Win95 downloads the correct driver see PRINTER_DRIVER.txt in the Samba docs. Moral of this story: RTFD. Matt. -- Matt Chapman E-mail: mattyc@cyberdude.com
> Hello,Hi> I am running samba 1.9.18p8-1 on a Debian Linux machine. ThisLinux kernel is the source of this message, so your post to samba@... was offtopic. See /usr/src/linux/net/ipv4/icmp.c, line around 680. [snipped]> The IPs apparently all come from Win NT servers. What is wrong with my > configuration, and how can I solve it? (other than pipe the messages to > /dev/null?)See the comment in the sources referenced above. And you can comment out that message from there anyway, if you are unable to fix it at any side. [snipped] Lace