From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: sandeen@sandeen.net, yongtaofu@gmail.com, xfs@oss.sgi.com
Subject: Re: xfs_iunlink_remove: xfs_inotobp() returned error 22 -- debugging
Date: Wed, 17 Apr 2013 02:24:17 +1000 [thread overview]
Message-ID: <20130416162417.GC13938@destitution> (raw)
In-Reply-To: <516C89DF.4070904@redhat.com>
On Mon, Apr 15, 2013 at 07:14:39PM -0400, Brian Foster wrote:
> Hi,
>
> Thanks for the data in the previous thread:
>
> http://oss.sgi.com/archives/xfs/2013-04/msg00327.html
>
> I'm spinning off a new thread specifically for this because the original
> thread is already too large and scattered to track. As Eric stated,
> please try to keep data contained in as few messages as possible.
>
> The data confirms Dave's theory where we are going off the end of the
> unlinked list when attempting to remove an inode, pass in NULLAGINO to
> xfs_inotobp() and the attempted conversion to a global inode number
> leads to EINVAL. The next question here is why wasn't the inode listed
> in the probe output on the unlinked inode list?
>
> Unfortunately we're probably going to require to start making some
> debug-level changes to the kernel to make progress on this issue. If you
> are able to recompile a kernel and/or xfs module (which you referred to
> doing in the previous thread), could you start with the patch appended
> to this message[1] and collect the xfs_iunlink and xfs_iunlink_remove
> tracepoint data the next time the problem occurs? E.g.,
>
> echo 1 > /sys/kernel/debug/tracing/events/xfs/xfs_iunlink/enable
> echo 1 > /sys/kernel/debug/tracing/events/xfs/xfs_iunlink_remove/enable
> ... reproduce ...
> cat /sys/kernel/debug/tracing/trace > trace.output
It's better to use trace-cmd for this. it will result in less
dropped events. i.e.:
$ trace-cmd record -e xfs_iunlink\*
... reproduce ...
^C
$ trace-cmd report > trace.output
> --- a/fs/xfs/linux-2.6/xfs_trace.h
> +++ b/fs/xfs/linux-2.6/xfs_trace.h
> @@ -581,6 +581,8 @@ DEFINE_INODE_EVENT(xfs_file_fsync);
> DEFINE_INODE_EVENT(xfs_destroy_inode);
> DEFINE_INODE_EVENT(xfs_write_inode);
> DEFINE_INODE_EVENT(xfs_clear_inode);
> +DEFINE_INODE_EVENT(xfs_iunlink);
> +DEFINE_INODE_EVENT(xfs_iunlink_remove);
>
> DEFINE_INODE_EVENT(xfs_dquot_dqalloc);
> DEFINE_INODE_EVENT(xfs_dquot_dqdetach);
> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index 796edce..a43bec5 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -1670,6 +1670,8 @@ xfs_iunlink(
> (sizeof(xfs_agino_t) * bucket_index);
> xfs_trans_log_buf(tp, agibp, offset,
> (offset + sizeof(xfs_agino_t) - 1));
> +
> + trace_xfs_iunlink(ip);
> return 0;
> }
>
> @@ -1820,6 +1822,8 @@ xfs_iunlink_remove(
> (offset + sizeof(xfs_agino_t) - 1));
> xfs_inobp_check(mp, last_ibp);
> }
> +
> + trace_xfs_iunlink_remove(ip);
> return 0;
I would suggest that the the tracing shoul dbe at entry of the
function, otherwise we won't get a tracepoint for the operation that
triggers the shutdown. (That's the reason most tracepoints in XFS
are at function entry...)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-04-16 16:23 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-15 23:14 xfs_iunlink_remove: xfs_inotobp() returned error 22 -- debugging Brian Foster
2013-04-16 16:24 ` Dave Chinner [this message]
2013-04-16 17:18 ` Brian Foster
2013-04-17 1:04 ` 符永涛
2013-04-17 1:35 ` 符永涛
2013-04-17 3:15 ` 符永涛
2013-04-17 3:48 ` 符永涛
2013-04-17 4:28 ` Eric Sandeen
2013-04-18 1:30 ` 符永涛
2013-04-18 6:45 ` 符永涛
2013-04-18 8:25 ` 符永涛
2013-04-18 11:41 ` Brian Foster
2013-04-18 15:23 ` 符永涛
2013-04-18 16:40 ` 符永涛
2013-04-18 17:03 ` Eric Sandeen
2013-04-18 18:35 ` Eric Sandeen
2013-04-18 20:59 ` Brian Foster
2013-04-19 6:40 ` 符永涛
2013-04-19 11:41 ` 符永涛
2013-04-19 14:59 ` Eric Sandeen
2013-04-19 15:13 ` 符永涛
2013-04-19 15:18 ` 符永涛
2013-04-19 16:16 ` Eric Sandeen
2013-04-19 16:47 ` 符永涛
2013-04-19 17:00 ` 符永涛
2013-04-19 17:04 ` Eric Sandeen
2013-04-19 17:08 ` 符永涛
2013-04-19 17:17 ` 符永涛
2013-04-20 0:03 ` 符永涛
2013-04-20 1:15 ` 符永涛
2013-04-20 2:51 ` 符永涛
2013-04-20 3:40 ` Eric Sandeen
2013-04-20 4:03 ` 符永涛
2013-04-20 4:11 ` 符永涛
2013-04-20 4:20 ` Eric Sandeen
2013-04-20 4:27 ` 符永涛
2013-04-20 10:10 ` 符永涛
2013-04-20 11:38 ` Brian Foster
2013-04-20 11:52 ` 符永涛
2013-04-20 12:58 ` Brian Foster
2013-04-20 13:12 ` 符永涛
2013-04-20 15:36 ` Eric Sandeen
[not found] ` <5172B73C.6000900@sandeen.net>
2013-04-20 23:52 ` 符永涛
2013-04-22 19:59 ` Eric Sandeen
2013-04-23 0:08 ` Dave Chinner
2013-04-23 0:52 ` Eric Sandeen
2013-04-23 1:31 ` 符永涛
2013-04-24 9:02 ` Dave Chinner
2013-04-24 10:21 ` 符永涛
2013-04-25 0:48 ` 符永涛
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=20130416162417.GC13938@destitution \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
--cc=yongtaofu@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.