kernel BUG with xfs_quota

[Chris Walker]

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

On Fri, Jul 10, 2009 at 12:00 AM, Eric Sandeen<sandeen at 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
>