linux-kernel - Re: 2.6.31-rc8: CIFS with 5 seconds hiccups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Sep 2009 17:27:53 -0400 (EDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Jeff Layton <jlayton@...hat.com>
cc:	linux-kernel@...r.kernel.org, samba@...ts.samba.org,
	linux-cifs-client@...ts.samba.org
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.

Download attachment "iptrace" of type "APPLICATION/octet-stream" (384828 bytes)