Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

edquota -t broken?

3 views
Skip to first unread message

Sven Willenberger

unread,
Jul 16, 2004, 6:32:31 PM7/16/04
to freebsd...@freebsd.org, cur...@freebsd.org
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

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

Sven Willenberger

unread,
Jul 20, 2004, 12:01:30 AM7/20/04
to freebsd...@freebsd.org, cur...@freebsd.org

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).

0 new messages