Description of Problem: edquota -t does not set grace period, grace period remains at either 6 or 7 days (see below) (edquota -t) 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): How Reproducible: 1.configure disk quotas (user or group) 2.run 'edquota -t' 3.restart quotas, reboot, whatever... watch as your grace period is ignored Actual Results: grace period not set. I tried all sorts of values. Grace period remains at default Expected Results: grace period should have been changed. Additional Information: 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.