[linux-cifs-client] 2.6.31-rc8: CIFS with 5 seconds hiccups

[Jeff Layton]

On Thu, 10 Sep 2009 15:42:28 -0400 (EDT)
Christoph Lameter <cl at linux-foundation.org> wrote:

> On Thu, 10 Sep 2009, Jeff Layton wrote:
> 
> > I assume that the 32 and 64 bit clients you have are calling "ls" in
> > the same dir. If so, maybe a similar capture from a 64-bit client might
> > help us see the difference?
> 
> 64 bit trace attached.

A couple of differences. First, the "ls's" were done in different
directories since they had different search patterns:

32 == \*
64 == \clameter\*

...did they also mount different shares from the server?

The 64-bit capture was done in a directory with only 50 files,
whereas the other one had at least 600-700 files (capture ends before
it finished listing the files). That may make quite a bit of difference
on the server (not sure how windows works internally in this case).

The only other substantive difference I see is that the Level of
Interest that the client is requesting is different:

32 == SMB_FIND_FILE_DIRECTORY_INFO
64 == SMB_FIND_FILE_ID_FULL_DIR_INFO

That probably means that the 32 bit client has disabled
CIFS_MOUNT_SERVER_INUM for some reason. That means that it's not asking
the server for the windows equivalent of inode numbers. We typically
disable that flag automatically if a query for the inode number of a
path fails.

Since these are the same server, that may be an indicator that the
server is serving out info from two different filesystem types (maybe
FAT vs. NTFS, or maybe even a CDROM or something). If so, then that may
help explain some of the performance delta there. I'd be more
interested to see how the 64 bit client behaves when it mounts the
exact same share and does an ls in the same directory as the 32 bit
client.

Cheers,
-- 
Jeff Layton <jlayton at redhat.com>