Messages in this thread | | | Date | Thu, 10 Sep 2009 17:27:53 -0400 (EDT) | From | Christoph Lameter <> | Subject | Re: 2.6.31-rc8: CIFS with 5 seconds hiccups |
| |
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. [unhandled content-type:application/octet-stream] | |