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]

Message-ID: <20090910165757.43b77874@tlielax.poochiereds.net>
Date:	Thu, 10 Sep 2009 16:57:57 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
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 15:42:28 -0400 (EDT)
Christoph Lameter <cl@...ux-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@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/