Windows 2000 - MS word updates slow to samba

[Mike Fitzpatrick]

Paul, thanks for your assistance.  I am beginning to believe it is a problem
with either MS Office 2000 or MS Windows 2000.

I copied the suspect Word file to a real Windows NT 4.0 SP6 server (on a
big Compaq server) and when I updated the Word file, it exhibited the
same slowness.

I did some better timing and figured that between the time it takes to type
one character and see it displayed in the Word document is approximately
8 - 10 seconds (when the document is on the real NT server or on our
Samba server ... via NFS).  So, I really don't have any big latency issues
due to NFS, disk IO, or network.

I found that there are 2 patches for Windows 2000 and 2 more patches
for Office 2000.  So, we are going to load these on the computers and
see what happens.

Thanks.

"Green, Paul" wrote:

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