From: Christian Kujau <lists@nerdbynature.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
Benny Halevy <bhalevy@panasas.com>, Chris Wedgwood <cw@f00f.org>,
linux-xfs@oss.sgi.com
Subject: Re: 2.6.24-rc2 XFS nfsd hang / smbd too
Date: Thu, 15 Nov 2007 08:51:36 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.0.99999.0711150840340.12443@sheep.housecafe.de> (raw)
In-Reply-To: <alpine.DEB.0.99999.0711142317010.12443@sheep.housecafe.de>
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:
[<c040914c>] mutex_lock_nested+0xcc/0x2c0
[<c016dc64>] do_lookup+0xa4/0x190
[<c016f6f9>] __link_path_walk+0x749/0xd10
[<c016fd04>] link_path_walk+0x44/0xc0
[<c016fd98>] path_walk+0x18/0x20
[<c016ff98>] do_path_lookup+0x78/0x1c0
[<c0170998>] __user_walk_fd+0x38/0x60
[<c0169bd1>] vfs_stat_fd+0x21/0x50
[<c0169ca1>] vfs_stat+0x11/0x20
[<c0169cc4>] sys_stat64+0x14/0x30
[<c01028d6>] 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.
next prev parent reply other threads:[~2007-11-15 7:51 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 7:04 2.6.24-rc2 XFS nfsd hang Chris Wedgwood
2007-11-14 7:43 ` Benny Halevy
2007-11-14 12:59 ` J. Bruce Fields
2007-11-14 22:31 ` Christian Kujau
2007-11-15 7:51 ` Christian Kujau [this message]
2007-11-15 14:44 ` 2.6.24-rc2 XFS nfsd hang / smbd too Christian Kujau
2007-11-15 22:01 ` Christian Kujau
2007-11-16 0:34 ` Chris Wedgwood
2007-11-16 9:17 ` 2.6.24-rc2 XFS nfsd hang Christian Kujau
2007-11-16 11:03 ` Chris Wedgwood
2007-11-16 14:19 ` Trond Myklebust
2007-11-16 21:43 ` Chris Wedgwood
2007-11-18 14:44 ` Christian Kujau
2007-11-18 15:31 ` Justin Piszcz
2007-11-18 22:07 ` Christian Kujau
2007-11-14 11:49 ` 2.6.24-rc2 XFS nfsd hang --- filldir change responsible? Chris Wedgwood
2007-11-14 22:48 ` Christian Kujau
2007-11-14 15:29 ` 2.6.24-rc2 XFS nfsd hang Christoph Hellwig
2007-11-14 17:39 ` J. Bruce Fields
2007-11-14 17:44 ` Christoph Hellwig
2007-11-14 17:53 ` J. Bruce Fields
2007-11-14 18:02 ` Christoph Hellwig
2007-11-14 18:08 ` J. Bruce Fields
2007-11-21 15:07 ` Christoph Hellwig
2007-11-21 19:03 ` J. Bruce Fields
2007-11-25 16:30 ` [PATCH] xfs: revert to double-buffering readdir Christoph Hellwig
2007-11-27 19:43 ` Chris Wedgwood
2007-11-29 23:45 ` Christian Kujau
2007-11-30 7:47 ` David Chinner
2007-11-30 7:22 ` Timothy Shimmin
2007-11-30 22:36 ` Stephen Lord
2007-11-30 23:04 ` Chris Wedgwood
2007-12-01 13:04 ` Stephen Lord
2007-12-03 15:11 ` Christoph Hellwig
2007-12-03 15:09 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.0.99999.0711150840340.12443@sheep.housecafe.de \
--to=lists@nerdbynature.de \
--cc=bfields@fieldses.org \
--cc=bhalevy@panasas.com \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).