Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757599AbXKOHv5 (ORCPT ); Thu, 15 Nov 2007 02:51:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755021AbXKOHvs (ORCPT ); Thu, 15 Nov 2007 02:51:48 -0500 Received: from ns2.g-housing.de ([81.169.133.75]:56309 "EHLO mail.g-house.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751806AbXKOHvr (ORCPT ); Thu, 15 Nov 2007 02:51:47 -0500 Date: Thu, 15 Nov 2007 08:51:36 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: LKML cc: "J. Bruce Fields" , Benny Halevy , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: 2.6.24-rc2 XFS nfsd hang / smbd too In-Reply-To: Message-ID: References: <20071114070400.GA25708@puku.stupidest.org> <473AA72C.6020308@panasas.com> <20071114125907.GB4010@fieldses.org> User-Agent: Alpine 0.99999 (DEB 796 2007-11-08) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2220 Lines: 58 On Wed, 14 Nov 2007, Christian Kujau wrote: > Yes, the nfsd process only got stuck when I did ls(1) (with or without -l) on > a NFS share which contained a XFS partition. Since NFS was not working (the nfsd processes were already in D state), to mount a CIFS share from the very same server (and the same client). I'm exporting the same /data share (JFS), but, since it's smbd I don't have to export every single submount (as it is with NFS): * with NFS: server:/data (jfs) server:/data/sub (xfs) * with CIFS: server:/data (containing both the jfs and the xfs partition as one single share to mount) Upon accessing the /data/sub part of the CIFS share, the client hung, waiting for the server to respond (the [cifs] kernel thread on the client was spinning, waiting for i/o). On the server, similar things as with the nfsd processes happened (although I know that the smbd (Samba) processes are running completely in userspace): http://nerdbynature.de/bits/2.6.24-rc2/nfsd/debug.3.txt.gz Sysrq-t again on the server: http://nerdbynature.de/bits/2.6.24-rc2/nfsd/dmesg.3.gz smbd D c04131c0 0 22782 3039 e242ad60 00000046 e242a000 c04131c0 00000001 e7875264 00000246 e7f88a80 e242ada8 c040914c 00000000 00000002 c016dc64 e7a3b7b8 e242a000 e7875284 00000000 c016dc64 f7343d88 f6337e90 e7f88a80 e7875264 e242ad88 e7a3b7b8 Call Trace: [] mutex_lock_nested+0xcc/0x2c0 [] do_lookup+0xa4/0x190 [] __link_path_walk+0x749/0xd10 [] link_path_walk+0x44/0xc0 [] path_walk+0x18/0x20 [] do_path_lookup+0x78/0x1c0 [] __user_walk_fd+0x38/0x60 [] vfs_stat_fd+0x21/0x50 [] vfs_stat+0x11/0x20 [] sys_stat64+0x14/0x30 [] sysenter_past_esp+0x5f/0xa5 ======================= So, it's really not NFS but ?FS related? Christian. -- BOFH excuse #199: the curls in your keyboard cord are losing electricity. - 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/