Silly reads from WinXP/OfficeXP against Samba 3.0

Shirish Kalele kalele at veritas.com
Tue Jul 15 17:23:02 GMT 2003


Another thing to look for is whether 'client-side offline caching' is
switched on. The CSC daemon on clients does independent tree-connects and
reads files in to cache them. Later, it periodically tree-connects again
to check whether the timestamps on the cached files have changed on the
server.

There used to be a bug in Samba where the CSC daemon would get the
impression that the size on the file had changed; the values returned in
queryfileinfo and ntcreat&x wouldn't match (afair), but this was fixed at
the time in all existing branches.

- Shirish

On Tue, 15 Jul 2003, Christopher R. Hertel wrote:

>Does the same happen against an NT or W2K server?
>
>We've seen similar (not the same) behavior in other cases.  There's
>"rabbit-pellet" mode, in which Windows Explorer on a W/98 or ME client
>will do short writes (512 bytes), each followed by a flush operation.  It
>is still not clear what triggers this.
>
>I can send you a capture if you'd like to see it.
>
>The problem with rabbit-pellet mode is that no one has ever seen Windows
>systems do this to one another.  It only happens against a third-party
>server (Samba, generally, but it may happen against others...dunno).
>It *seems* as though rabbit-pellet mode is triggered by pass-through
>authentication on the server, but it is not consistent.  There may also be
>timing issues involved.
>
>So, the thing to figure out first is whether or not XP does the same thing
>against other servers.  If so, we may be able to get Microsoft to fix the
>bug that causes it.  If it only happens against Samba, then we need to
>figure out what we are doing that is "different".
>
>As with much of Microsoft's code, it is likely that we're just causing
>Windows to wander down some untested code path.  These are probably bugs
>that have never been tested because none of Microsoft's products exercise
>them.  I doubt that this behavior is intentional.
>
>Chris -)-----
>
>On Tue, Jul 15, 2003 at 04:27:48PM +0200, Volker Lendecke wrote:
>> Hi!
>>
>> 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 exactly easy :-(
>>
>> Any idea anybody?
>>
>> Volker
>
>
>
>--
>"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
>Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
>jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
>ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
>OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org
>




More information about the samba-technical mailing list