| To: | Eric Sandeen <sandeen@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: kernel BUG with xfs_quota |
| From: | Chris Walker <christopher.walker@xxxxxxxxx> |
| Date: | Fri, 10 Jul 2009 10:57:14 -0400 |
| Cc: | xfs@xxxxxxxxxxx |
| Dkim-signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MWkfhr4mipIG+LMO9Z6A/1EnFNi2+GXMsnP3n99McHU=; b=dMPLKv57ovcIlq/wdK30GqvMvgWWzg/3vqqLVHg9lZMCKfZKyMBTA/5L38sfjtpaKi I03/faE/Um0OLSYJUt4oX18G6Lv1YO32K3WJ/qfoYCk5yLWUZANp0T1x4kcephR2iqPG owKvYXznouiCpxD3QErebJaAxBhEeAcZzomdo= |
| Domainkey-signature: | a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ePQFaoaPI0y17D08P7ustinfiSu01qRTZbT38QrGKQAEKdIpETVdPBR4VdNRo3RRbE iv/ISb3CJ5sRPe94rT7MtZ5wDoelSAmN53eV/OmImM5KG155zcLFYLQ222QN/ukmeoWZ H4YL3i3ukpS/EBM74gG4VmYEXLdFWmWzQXOMg= |
| In-reply-to: | <4A56BCDE.2010609@xxxxxxxxxxx> |
| References: | <554e24be0907091624s2dd439b2vfd7062f6b866c7f@xxxxxxxxxxxxxx> <4A56BCDE.2010609@xxxxxxxxxxx> |
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@xxxxxxxxxxx> 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
>
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: xfs_repair stops on "traversing filesystem...", Eric Sandeen |
|---|---|
| Next by Date: | Re: kernel BUG with xfs_quota, Eric Sandeen |
| Previous by Thread: | Re: kernel BUG with xfs_quota, Eric Sandeen |
| Next by Thread: | Re: kernel BUG with xfs_quota, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |