Red Hat Bugzilla – Bug 52555
if grace period changed with edquota -t, users over quota are not effected
Last modified: 2007-04-18 12:36:35 EDT
Description of Problem:
edquota -t does not set grace period, grace period remains at either 6 or 7 days (see below)
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
Filesystem Block grace period Inode grace period
/dev/hda6 8minutes 8minutes
[beavis@phoenix /]$ quota -g beavis
Disk quotas for group beavis (gid 22222):
Filesystem blocks quota limit grace files quota limit grace
/dev/hda6 252* 200 300 6days 6 0 0
Version-Release number of selected component (if applicable):
1.configure disk quotas (user or group)
2.run 'edquota -t'
3.restart quotas, reboot, whatever... watch as your grace period is ignored
grace period not set. I tried all sorts of values. Grace period remains at default
grace period should have been changed.
Several of my customers need this functionality. We really should try to fix this before release especially since quotas were only about 25% functional in 7.1
The grace period is set properly; "quota" is just reporting it wrong (run
edquota again, and your changes should be reflected).
No, there is a real problem. the grace time is not adjusted downwards (or
upwards) if the length of the grace time is changed with edquota -t and the
user is already exceeding quota. If they clean up and then exceed quota
again, the grace will be properly adjusted.
I'm bringing this up with the maintainer, the problem is deep.
The maintainer says that changing the behaviour to match what you expect would
be _very_ difficult. And then, there is the question of semantics: should
files with "grandfathered" quotas keep their old grace times, or adopt the new
grace time? People might argue either way.