edquota -t broken?
Sven Willenberger
sven at dmv.com
Fri Jul 16 15:30:29 PDT 2004
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
More information about the freebsd-stable
mailing list