Re: 2.6.31-rc8: CIFS with 5 seconds hiccups

[Christoph Lameter]

On Thu, 10 Sep 2009, Jeff Layton wrote:

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

Right. 32 bit cannot mount the clameter directory for strange reasons. I
have to go one level higher.

> 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).

Right. I just remounted the 64 bit on the same directory. No delays.

> 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.

I added the serverino option on the 32 bit system. No effect.

> 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.

No its all on the same file system.

New capture attached for same directory.

Attachment: iptrace
Description: 64 bit same directory