At 8:29 PM -0800 12/11/02, Eric Lee Steadle wrote:

>I have a few Win2k boxes that I've noticed extremely poor write performance
>on when writing to NT4 machines. Looking at a trace I took of a reasonably
>large file write (100meg), I see the following behavior:
>
>- 2000 sends across a Write_AndX packet for one byte, at a start position of
>5119 (ending at 5120).
>- 2000 then sends an smb_com_transact2 (SMB_QUERY_FILE_STANDARD_INFO)
>request.
>- 2000 sends a Write request for zero bytes, at 5120.
>- 2000 sends a Write AndX command for 5120 bytes, starting at byte 0.
>
>This repeats until the entire file is transferred.
>
>I'm used to seeing DOS-based or Explorer-based file transfers using just the
>Write AndX command for the number of bytes advertised by the server in
>MaxBuffer, without the other three packets.
>
>I've read that the one byte and zero byte writes are an attempt to truncate
>the file, though I can't say that I understand what this means. Has anyone
>seen the behavior above, and explain what the first three SMBs are trying to
>do?

I've spent a fair bit of time playing with this aspect of the protocol. I
still can't really answer the question, but here are some comments...

"Extremely poor" write performance is subjective. Looking at a trace one
can see where all the time is going. If it is mostly in the 4th packet
exchange then who cares about the first three? It is worth examining
inter-packet times near the end of the 100M as well as at the beginning -
performance can (but ideally shouldn't) be a function of file size or
offset.

I've seen client and server behaviours change not just with OS releases,
but also between NTFS and FAT filesystems. What you've observed coulde
2000's attempt to make up for a real or potential deficiency on the server.

A zero length write is defined to set the file length to that offset. This
is an "obsolete" (backward compatible to the stone age) mechanism but is
limited to 32 bit offsets. A zero length "write andx" does not set file
length - the modern mechanism is to use a transact2 set file info.

When the file length is being increased by either of those mechanisms, or
by writing data starting at an offset beyond the end of file, "specs" say
that the intervening bytes are filled with zeroes. Old servers do not all
comply with that - I've seen nonzero bytes returned by NT4 (hard to
reproduce) and by 98 (easy) even when "flush" commands are sent between the
write and the read.

When increasing file length and the server is Win2000 I have never seen
non-zero intervening bytes returned. But with very large files horrible
performance is easy to produce - perhaps "sparse" files are not the default.

When you figure this out please let me know the results!

--
Conrad Minshall ... conradapple.com ... 408 974-2749
Alternative email addresses: radacm.org and conradmac.com.
----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]