Date: Mon, 19 Jul 2004 23:57:24 -0400 From: Sven Willenberger <sven@dmv.com> To: freebsd-stable@freebsd.org Cc: current@freebsd.org Subject: Re: edquota -t broken? Message-ID: <40FC9824.9060003@dmv.com> In-Reply-To: <1090016941.32571.22.camel@lanshark.dmv.com> References: <1090016941.32571.22.camel@lanshark.dmv.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40FC9824.9060003>