Re: kernel BUG with xfs_quota

[Eric Sandeen <sandeen@sandeen.net>]

Chris Walker wrote:
> Thanks a lot for your response Eric, I didn't realize that debugging
> could lead to problems (perhaps the EXPERIMENTAL should have warned
> me!)  I will recompile without debugging.  I'm a bit surprised that
> debugging could lead to general filesystem instability -- I assumed it
> was a 'read-only' process.
> Thanks!
> Chris

Well, in general the asserts should all be valid, but they are
unforgiving, hence the stern warnings in the config help.  Rather than
printing out detailed info (though there is some of that),
CONFIG_XFS_DEBUG will also trigger an intentional BUG(); in any of the
assert conditions... so it's dangerous.  If you are hitting some other
problem, running with CONFIG_XFS_DEBUG may catch the problem sooner, but
I would not recommend running with it in general production.

-Eric


> On Fri, Jul 10, 2009 at 12:00 AM, Eric Sandeen<sandeen@sandeen.net> wrote:
>> Chris Walker wrote:
>>> Hello,
>>>
>>> I ran an xfs_quota command earlier (xfs_quota -x -c 'limit -g
>>> bsoft=2048g bhard=2148g hepl' /seltzer_lab), which triggered a kernel
>>> BUG:
>>>
>>> Assertion failed: dst->d_btimer != 0, file:
>>> fs/xfs/quota/xfs_qm_syscalls.c, line: 927
>> Well, you hit this:
>>
>> #ifdef DEBUG
>>        if (((XFS_IS_UQUOTA_ENFORCED(mp) && dst->d_flags ==
>> XFS_USER_QUOTA) ||
>>             (XFS_IS_OQUOTA_ENFORCED(mp) &&
>>                        (dst->d_flags & (XFS_PROJ_QUOTA |
>> XFS_GROUP_QUOTA)))) &&
>>            dst->d_id != 0) {
>>                if (((int) dst->d_bcount >= (int) dst->d_blk_softlimit) &&
>>                    (dst->d_blk_softlimit > 0)) {
>>                        ASSERT(dst->d_btimer != 0);
>>                }
>> ...
>>
>> which first raises the question, why are you running with
>> CONFIG_XFS_DEBUG? :)
>>
>> I'm no quota guru, but this is something like...
>>
>> If quota is enabled and the block count is over a non-0 soft limit, then
>> assert that the timer is non-0 (the timer being how much time is left
>> before service is refused.
>>
>> It also got all those values off the disk just prior to the ASSERT.
>>
>> ... and I'm not sure what the problem may be.  But you hit an internal
>> debugging assert which is only on with CONFIG_XFS_DEBUG, you may get
>> away with just running without that for now :)
>>
>> -Eric
>>
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs