Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752388AbZIROZW (ORCPT ); Fri, 18 Sep 2009 10:25:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752208AbZIROZT (ORCPT ); Fri, 18 Sep 2009 10:25:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21201 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752181AbZIROZP (ORCPT ); Fri, 18 Sep 2009 10:25:15 -0400 Date: Fri, 18 Sep 2009 10:24:18 -0400 From: Jeff Layton To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, samba@lists.samba.org, linux-cifs-client@lists.samba.org Subject: Re: 2.6.31-rc8: CIFS with 5 seconds hiccups Message-ID: <20090918102418.5d84931e@tlielax.poochiereds.net> In-Reply-To: References: <20090909125352.1c7b57d2@tlielax.poochiereds.net> <20090909132039.1ca47cd4@tlielax.poochiereds.net> <20090909140257.35ede0cc@tlielax.poochiereds.net> <20090909205548.4858b524@zanovar.poochiereds.net> <20090910153347.2f2616e8@barsoom.rdu.redhat.com> <20090910165757.43b77874@tlielax.poochiereds.net> <20090910201932.5b8356e2@tlielax.poochiereds.net> <20090915183405.2797b05e@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2589 Lines: 75 On Wed, 16 Sep 2009 12:26:04 -0400 (EDT) Christoph Lameter wrote: > On Tue, 15 Sep 2009, Jeff Layton wrote: > > > Yow, that version of mount.cifs is really old. I wonder if it may be > > passing bad mount options to the kernel? Might be interesting to strace > > that. Something like: > > > > # strace -f -s 256 -e mount mount -t cifs //chiprodfs2/company /mnt -ouser=clameter,domain=xxx > > > > ...it'll probably have a cleartext password in it so you might want to > > doctor the options a bit before sending along if you do. > > > > Alternately, you might just want to try a newer version of mount.cifs > > and see whether that fixes this. > > Tried a newer version of mount.cifs without any change. > Ok, good to rule that out then. > > > I cannot mount the clameter dir on the 32 bit box. Hangs. So I will mount > > > /company. > > > > > > > Actually, the trace of a hanging mount would probably be interesting. > > > > Does the 32-bit capture that you sent represent a mount attempt that > > hung? Or was it successful? > > No it was successful. > Hmm, ok. That isn't going to tell me as much as a mount that fails. For now, I suggest that we focus on determining why these mounts hang/fail. After that we can see whether the solution there has any bearing on why the server is so slow to respond to this particular client. > > What's the "devname" that you're giving to the mount command for the > > "clameter" dir? If there's more than 1 path component after the > > hostname, then the problem may be in the old version of mount.cifs. > > Some of them had broken handling for path prefixes. > > its //machinename/company/clameter > > So two components. > Also good to know. What we should probably do at this point is track down why the 32-bit client has such a hard time mounting the clameter dir. Here's what would be most helpful: 1) some debug log info of the mount attempt: # modprobe cifs # echo 7 > /proc/fs/cifs/cifsFYI ...then attempt the mount. After it hangs for a few seconds, ^c the mount to kill it. Collect the output from dmesg and send it to me. That should give me some idea of what the client is doing during this phase. If you can simultaneously capture wire traffic during the same mount attempt that would also be helpful. Cheers, -- Jeff Layton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/