xfs
[Top] [All Lists]

Re: 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.

To: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Subject: Re: 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 1 Dec 2009 10:38:18 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0911300819010.20343@xxxxxxxxxxxxxxxx>
References: <alpine.DEB.2.00.0911300819010.20343@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Nov 30, 2009 at 08:22:03AM -0500, Justin Piszcz wrote:
> Hi,
>
> 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.

> 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
somewhere.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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