From owner-freebsd-stable@FreeBSD.ORG Tue Jul 20 03:59:18 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED28816A4CE; Tue, 20 Jul 2004 03:59:17 +0000 (GMT) Received: from smtp-gw-cl-c.dmv.com (smtp-gw-cl-c.dmv.com [216.240.97.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D0E943D66; Tue, 20 Jul 2004 03:59:17 +0000 (GMT) (envelope-from sven@dmv.com) Received: from mail-gw-cl-b.dmv.com (mail-gw-cl-b.dmv.com [216.240.97.39]) i6K3xG9D019858; Mon, 19 Jul 2004 23:59:16 -0400 (EDT) (envelope-from sven@dmv.com) Received: from [192.168.1.2] (dogpound.dyndns.org [64.45.134.154]) by mail-gw-cl-b.dmv.com (8.12.9/8.12.9) with ESMTP id i6K3xFnq078284; Mon, 19 Jul 2004 23:59:16 -0400 (EDT) (envelope-from sven@dmv.com) Message-ID: <40FC9824.9060003@dmv.com> Date: Mon, 19 Jul 2004 23:57:24 -0400 From: Sven Willenberger User-Agent: Mozilla Thunderbird 0.7+ (Windows/20040715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1090016941.32571.22.camel@lanshark.dmv.com> In-Reply-To: <1090016941.32571.22.camel@lanshark.dmv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 cc: current@freebsd.org Subject: Re: edquota -t broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2004 03:59:18 -0000 Sven Willenberger wrote: > Having never had to concern myself with changing the grace period on > quota filesystems I never came across this issue before. Using the -t > flag to edquota to change the grace period on the file system in > question has utterly no effect. Whether I take someone who was > overquota, raise their quota and lower it, or cause a new user to go > overquota, the grace period always starts counting down from 7 days. > > This occurs on 4.7 FreeBSD as well as 5.2.1-P8. The odd thing is that I > can go into /usr/src/ufs/ufs/quota.h and change the #DEFINE MAX_DQ_TIME > to equal 30 days instead of 7 days and then recompiling quota.c edquota. > c and so on. > > When I invoke edquota -t -f /usr/home for example it *does* display: > > Time units may be: days, hours, minutes, or seconds > Grace period before enforcing soft limits for users: > /usr/home: block grace period: 30 days, file grace period: 0 days > > But this has utterly no effect on the quota reporting. Just to check if > maybe it was the quota program misreporting it, I wrote a quick c > program to check the value of dqb_btime from the structure defined in > quota.h: > > struct dqblk { > u_int32_t dqb_bhardlimit; /* absolute limit on disk blks > alloc */ > u_int32_t dqb_bsoftlimit; /* preferred limit on disk blks > */ > u_int32_t dqb_curblocks; /* current block count */ > u_int32_t dqb_ihardlimit; /* maximum # allocated inodes + > 1 */ > u_int32_t dqb_isoftlimit; /* preferred inode limit */ > u_int32_t dqb_curinodes; /* current # allocated inodes */ > int32_t dqb_btime; /* time limit for excessive disk > use */ > int32_t dqb_itime; /* time limit for excessive > files */ > }; > > After checking the value of that from a freshly overquota user and > subtracting the current unix time, I was left with 7 days. > > Any ideas on this one? Solved it by editing the quota.h in the source tree, rebuilding and installing the kernel and rebooting. Seems like a worthless flag to the edquota command if one needs to rebuild a kernel to change it. At first I thought that maybe the quota.h #DEFINE was for a maximum grace period, but that didn't hold water as I could not get the system to use a value less than 7 days either. I didn't try to reboot after using edquota -t so I don't know if that would have done anything (but I doubt it as I ran quotacheck after using that command). Anyway, perhaps this could be added as a kernel option (options QUOTA_GRACE or something along those lines?). I realize that most people have gone to virtuser type systems or massive storage where quotas are not an issue, but there are still servers (like some of ours) where we have actual (/etc/passwd) users that we need to put some constraints on (or they will never empty/prune their email boxes for example). Sven