From owner-freebsd-current@FreeBSD.ORG Fri Jul 16 22:30:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1DF316A4CE; Fri, 16 Jul 2004 22:30:29 +0000 (GMT) Received: from smtp-gw-cl-d.dmv.com (smtp-gw-cl-d.dmv.com [216.240.97.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB2D43D1D; Fri, 16 Jul 2004 22:30:29 +0000 (GMT) (envelope-from sven@dmv.com) Received: from lanshark.dmv.com (lanshark.dmv.com [216.240.97.46]) i6GMUSRv087937; Fri, 16 Jul 2004 18:30:28 -0400 (EDT) (envelope-from sven@dmv.com) From: Sven Willenberger To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Fri, 16 Jul 2004 18:29:01 -0400 Message-Id: <1090016941.32571.22.camel@lanshark.dmv.com> Mime-Version: 1.0 X-Mailer: Evolution 1.5.9 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.39 cc: current@freebsd.org Subject: edquota -t broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2004 22:30:29 -0000 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? Sven