[Top] [All Lists]

Re: XFS DEBUG: Assertions cause kernel OOPS.

To: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Subject: Re: XFS DEBUG: Assertions cause kernel OOPS.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 2 Dec 2009 10:58:03 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.0912011338000.1185@xxxxxxxxxxxxxxxx>
References: <alpine.DEB.2.00.0911300819010.20343@xxxxxxxxxxxxxxxx> <20091130233818.GE30608@xxxxxxxxxxxxxxxx> <alpine.DEB.2.00.0912011338000.1185@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Dec 01, 2009 at 01:39:06PM -0500, Justin Piszcz wrote:
> 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?

Yes, it appeared to be caused by log IO not completing, right?

> How should  
> one get more information on a filesystem lockup if we cannot have debug  
> enabled for the filesystem?

The debug code in XFS won't tell you anything extra about a lock-up
unless it trips an ASSERT before the lockup that is related to the
lock-up. My experience with hangs like the above are that they
generally are not related to the filesystem at all; most of the time
it is IO not being completed by the lower layers for some reason,
and no amount of filesystem level debug will help solve that

> Should there be a user-debug option which it 
> will include more verbosity if/when the xfs kernel processes lockup?

See /proc/sys/fs/xfs/error_level. That can turn up the verbosity of
error reporting without needing DEBUG compiled in.


Dave Chinner

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