[Top] [All Lists]

Re: XFS DEBUG: Assertions cause kernel OOPS.

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS DEBUG: Assertions cause kernel OOPS.
From: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Date: Tue, 1 Dec 2009 13:39:06 -0500 (EST)
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20091130233818.GE30608@xxxxxxxxxxxxxxxx>
References: <alpine.DEB.2.00.0911300819010.20343@xxxxxxxxxxxxxxxx> <20091130233818.GE30608@xxxxxxxxxxxxxxxx>
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Tue, 1 Dec 2009, Dave Chinner wrote:

On Mon, Nov 30, 2009 at 08:22:03AM -0500, Justin Piszcz wrote:

I wanted to compile my kernel with DEBUG for XFS and also kernel frame pointers
to catch any issues.

However, DEBUG for XFS does more harm than good?

DEBUG is there for developers, not end users. Often the debug code
will assert fail or panic where the situation is not fatal but
indicative of some problem that should be looked into further.

Recall that issue that I was having with asterisk installed? How should one get more information on a filesystem lockup if we cannot have debug enabled for the filesystem? Should there be a user-debug option which it will include more verbosity if/when the xfs kernel processes lockup?

I tried to install bonnie++:
# apt-get install -y bonnie++

And then this happened:

[ 1578.768558] Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
[ 1578.769252]  [<ffffffff811eb916>] xfs_bmapi+0x66/0x1940
[ 1578.769252]  [<ffffffff81260c51>] ? __up_read+0x91/0xb0
[ 1578.769252]  [<ffffffff8123a0a7>] ? xfs_buf_free+0xc7/0x110
[ 1578.769252]  [<ffffffff8123a1e6>] ? xfs_buf_rele+0xf6/0x130
[ 1578.769252]  [<ffffffff8122e70a>] ? xfs_trans_brelse+0x19a/0x2a0
[ 1578.769252]  [<ffffffff811f7ac7>] ? xfs_da_brelse+0x77/0x120
[ 1578.769252]  [<ffffffff810bf63d>] ? filldir+0x9d/0xe0
[ 1578.769252]  [<ffffffff8120225a>] xfs_dir2_leaf_getdents+0x61a/0x780
[ 1578.769252]  [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
[ 1578.769252]  [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
[ 1578.769252]  [<ffffffff811fc6ec>] xfs_readdir+0x10c/0x110
[ 1578.769252]  [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
[ 1578.769252]  [<ffffffff8123b4f4>] xfs_file_readdir+0x34/0x50
[ 1578.769252]  [<ffffffff810bf7f8>] vfs_readdir+0xa8/0xc0
[ 1578.769252]  [<ffffffff810bf963>] sys_getdents+0x83/0xe0
[ 1578.769252]  [<ffffffff8102d1ab>] system_call_fastpath+0x16/0x1b

That is indicative of trying to map more blocks that we can fit
in the block map array during directory leaf readahead. That is
definitely not a problem for production systems, but definitely
indicates that the readahead loop termination has a bug in it


Dave Chinner

xfs mailing list

<Prev in Thread] Current Thread [Next in Thread>