2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.

[Justin Piszcz]

On Tue, 1 Dec 2009, Dave Chinner wrote:

> 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.
Dave,

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
> somewhere.
>
> Cheers,
>
> Dave.
> -- 
> Dave Chinner
> david at fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>