From owner-freebsd-hackers Thu Mar 2 1:25:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id CE6CD37C005 for ; Thu, 2 Mar 2000 01:25:26 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.9.3/8.9.3) with ESMTP id KAA23504 for ; Thu, 2 Mar 2000 10:25:22 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.9.3/8.9.3) with ESMTP id KAA26352 for ; Thu, 2 Mar 2000 10:25:21 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.9.3/8.9.3) id KAA61902 for ; Thu, 2 Mar 2000 10:25:21 +0100 (CET) Date: Thu, 2 Mar 2000 10:25:21 +0100 From: Andre Albsmeier To: freebsd-hackers@freebsd.org Cc: andre.albsmeier@mchp.siemens.de Subject: Re: Fix for quotas grace time when using chown and soft limits are hit again Message-ID: <20000302102521.A23506@internal> References: <20000301221956.A10086@internal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000301221956.A10086@internal>; from andre@internal on Wed, Mar 01, 2000 at 10:19:56PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [follow up to myself...] On Wed, 01-Mar-2000 at 22:19:56 +0100, Andre Albsmeier wrote: > Here is a problem with FreeBSD's quotas that I have observed > for a long time now but finally found some time to track it down: > > Let's assume the following settings on a quota enabled system: > > soft limits : 100MB > hard limits : 200MB > grace period: 7 days > > ... > > --- /sys/ufs/ufs/ufs_quota.c Mon Aug 30 17:56:23 1999 > +++ ufs_quota.c Wed Mar 1 21:27:14 2000 > @@ -163,6 +163,10 @@ > (void) tsleep((caddr_t)dq, PINOD+1, "chkdq2", 0); > } > dq->dq_curblocks += change; > /* check if we hit the soft limits */ > + if (dq->dq_curblocks >= dq->dq_bsoftlimit && dq->dq_bsoftlimit) > /* check if we have been below the soft limits before */ > + if (dq->dq_curblocks - change < dq->dq_bsoftlimit) > /* yes, update the timer */ > + dq->dq_btime = time_second + > + VFSTOUFS(ITOV(ip)->v_mount)->um_btime[i]; > dq->dq_flags |= DQ_MOD; > } > return (0); > @@ -279,6 +283,10 @@ > (void) tsleep((caddr_t)dq, PINOD+1, "chkiq2", 0); > } > dq->dq_curinodes += change; > /* same as above for inodes */ > + if (dq->dq_curinodes >= dq->dq_isoftlimit && dq->dq_isoftlimit) > + if (dq->dq_curinodes - change < dq->dq_isoftlimit) > + dq->dq_itime = time_second + > + VFSTOUFS(ITOV(ip)->v_mount)->um_itime[i]; > dq->dq_flags |= DQ_MOD; > } > return (0); > Couldn't stand waiting any longer so I tried it on a test box and it seems to work :-). However, I am interested in hearing the opinion from the filesystem specialists if the issue: a) is really a bug b) can be fixed (changed) with the above patch properly Thanks to all in advance, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message