[linux-cifs-client] Find_First with InfoLevel 0x104(260) doesn't

[Naidu Bollineni]

I am wondering if an attempt to use Infolevel 0x104 on FirstFirst is
showing correct output.

 

For me it did not because the structure FILE_BOTH_DIRECTORY_INFO has
member Shortname declared __u8 inctead of __u16.

 

Changing it to __u16 is showing correct result, and ethereal trace does
confirm there are 24 bytes before the real Unicode FileName of the
entry.

 

Naidu Bollineni

Senior Member Technical Staff

Kazeon Systems

naidu at kazeon.com

www.kazeon.com

________________________________

From: linux-cifs-client-bounces+naidu=kazeon.com at lists.samba.org
[mailto:linux-cifs-client-bounces+naidu=kazeon.com at lists.samba.org] On
Behalf Of Steven French
Sent: Wednesday, July 20, 2005 9:47 AM
To: dean.davis at mbg-inc.com
Cc: linux-cifs-client at lists.samba.org
Subject: Re: [linux-cifs-client] Slow Samba Share access to CIFS-mount -
Win2k3Share

 

Your post did not included enough information to be conclusive about the
cause of the performance change after update of the server side to newer
Windows server version, but there are a couple things that could be done
to isolate it. I like to use more granular performance tools (iozone
e.g., or the connectathon "nfs" tests run in timing "-t" mode) to
compare before and after - and then compare with the network traces to
see whether any particular type of request is slower after the change. 

As a long shot (in the dark) .... A new performance consideration which
I had not noticed before is TCP ack timeouts - depending on the size of
the tcp window and various issues relating to TCP's "nagle" algorithm,
TCP acks can be delayed to allow acks to be sent with subsequent
requests or responses. This can be a disaster for performance of one
process on one client talking to one server over very high speed links
since it results in much dead time on the wire in which neither end is
doing anything. Tuning around this (e.g. changing the sizes of the
request buffer via insmod or on the server side) is a possibility and in
any case is easy enough to do that it is worth trying. I am looking at
how to disable the nagle algorithm code on the socket on the client as
well. This may have nothing to do with it, but I stumbled across it when
I saw that a performance improvement I had made in some cases made
things an order of magnitude slower when larger responses were sent. 


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

-------------- next part --------------
HTML attachment scrubbed and removed