Silly reads from WinXP/OfficeXP against Samba 3.0
tristan.ball at vsl.com.au
Tue Jul 15 23:53:18 GMT 2003
While it's not quite the same as your environment, we saw very
similar behaviour, so maybe this will help.
Word 2000, with "track changes" on.
Rational Reqpro (forget version). - which integrates word documents with
an SQL DB for project requirements management.
Particularly when scrolling through the document, word would go insane
with <512 byte reads - as far as I can tell, the track changes mode
means the word document has it's content split all over the file, so
word has to keep jumping around all over the place. This is made worse
by the fact that by default, word only buffers about 64K of the file in
memory, and scrolling meant we "jumped out" of that buffer constantly.
On a windows<->system, this behaviour is hidden by oplock caching.
However, word had a habit of opening the document 2 or 3 times, which
causes samba to break the oplock. I assume windows has some magic to
detect this behaviour, and keep the client cache valid.
We worked around the problem with a registry hack to cause word to
buffer more of the document at a time:
There's probably a similar option for XP.
> -----Original Message-----
> From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
> Sent: Wednesday, July 16, 2003 12:28 AM
> To: samba-technical at samba.org
> Subject: Silly reads from WinXP/OfficeXP against Samba 3.0
> Here I have a repeatable case: Office XP SP2 on WinXP reads a
> file, and
> during the first requests everything looks fine. Then after some time
> the machine starts to read *HUGE* amounts of 512
> byte-fragments from the
> .doc-file. This results in ~140000 packets whereas the same operations
> only use ~4000 packets when the file is on 2k.
> I already tried 'max xmit = 4356' to match 2k buffer size negotiation,
> but that did not help. One thing that I also found is that the client
> seems to actively use the multi-request feature of 2k.
> I can provide sniffs and tests with a patched Samba, but I'm
> currently a
> bit lost. Staring at a dump of 140000 packets is not exacly easy :-(
> Any idea anybody?
More information about the samba-technical