Windows 2000 - MS word updates slow to samba

[Green, Paul]

Mike Fitzpatrick <Michael_S_Fitzpatrick at raytheon.com> writes:

> We have some Windows 2000 clients connecting to our Samba server.
> When they try to update a table in a MS Word document, each character
> update can take several seconds (15-45 seconds), depending upon the
> size of the document.  One of the MS Word docs we have is 500 K and
> it can take about 10 seconds to enter 1 character into the table (or even
> delete a character from the table).

Try this from DOS; if the problem is at the Samba end then all of the PC
clients should experience the same behavior. If so,  the problem is easier
to understand and reproduce when things are simple. Try:

  NET USE * sharename  {say it picks J:}
  COPY J:testfile.doc

Time this operation from both NT4 and W2K.  This is essentially what Word is
doing, anyway, when someone opens the file to edit it.

> We have tried Samba 2.0.7 and 2.2.0 both running on a Solaris 8 system.
> The MS Word document is NFS mounted from a Sun Server onto the Sun
> running Samba.

Recall that MS Word tends to put its temporary file into the same directory
as the file it is reading. This is rather non-optimal (even pessimal). See
MS KB article Q211632 for details. You might get some improvements by
putting the temp files on a local disk.

> We do not have the slow down when updating the file with Windows NT 4.0
> or Windows NT Terminal Server.

I also have a case where an NT4 client works, and a W2K client fails. See
below.

> When I truss on the smbd process during the user key-strokes, it appears
> the client is retrieving several portions of the file because I see
repeating
> send, poll, read, read, llseek, read system calls.  These system calls
repeat
> numerous times.

I have traces that seem to show that Windows clients seemingly do not trust
the underlying network layer, and when told that an error has occurred, try
the same operation again and again.  So again, this is not a surprise. And
it sure makes for gigantic Samba debugging log files...

> Has anyone experienced this problem and do you have any suggestions
> to correct it?  Could there be some configuration change we can do on
> the Windows 2000 client?
>
> Thanks, Michael Fitzpatrick

Caveat: I have Samba 2.0.7 running on a relatively new implementation of
POSIX, and some of what I am about to report could be due to latent,
undiscovered bugs in our own POSIX layer, and not a problem in Samba. But I
don't think so, because I ran a careful test with a baseline and changed
only these few lines of code.

I have a repeatable test case that shows an NT4 client able to copy a small
file from Samba to a PC, while a W2K client is unable to copy the very same
file. This is the same problem I reported to this list on August 14th. Since
that time I've tracked it down and found a fix in the CVS archives.

This is the fix. It was applied to Samba on Friday May 5, 2000 @ 12:37 by
Jeremy. (See /source/cvs.log). Note: this is my reconstruction of the
change. I didn't actually pull the change from the CVS archive. YHBW.

*** 2.0>source>smbd>fileio.c  Tue Aug 21 18:16:39 2001
--- 2.0vos>source>smbd>fileio.c    Tue Aug 21 18:17:15 2001
***************
*** 121,126 ****
--- 121,128 ----

    if (n > 0) {
      readret = read(fsp->fd_ptr->fd,data,n);
+     if (readret == -1)
+       return -1;
      if (readret > 0) ret += readret;
    }

My test case is a file that is 4096 bytes in length.  But 4097 and 4098 also
fail on W2K/SP1 and work on NT4(no SP).

I think it is a very long shot that you are seeing the same problem. But you
never know...

I'd like to see this fix {well, JRA's official copy of same} applied to the
current 2.0.* tree...thanks in advance.

Hope this helps a little.
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request.