Bug 1072404
| Summary: | Wrong value for expired grace period retrieved over network | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jan Kurik <jkurik> |
| Component: | quota | Assignee: | Petr Pisar <ppisar> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.4 | CC: | pm-eus, ppisar, psklenar, tmaria |
| Target Milestone: | rc | Keywords: | Patch, ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://sourceforge.net/p/linuxquota/bugs/115/ | ||
| Whiteboard: | |||
| Fixed In Version: | quota-3.17-21.el6_5 | Doc Type: | Bug Fix |
| Doc Text: |
Previously, the integer type was misinterpreted if a quota tool displayed the grace time for an NFS-mounted file system when the soft quota limit for the current user had been exceeded, and the grace quota time had already expired. As a consequence, the quota command incorrectly reported a large number of days instead of the "none" value. This update fixes the misinterpretation of the integer type used to transfer grace times over the network. In addition, this update limits the range of possible values to 32-bit signed integer boundaries in order to ensure interoperability between NFS servers and clients with a different CPU word size. As a result, the quota tools correctly report the grace time that differ from the server time in the range from -2^31+1 to 2^31 seconds. Lower values are reported as expired, higher as a maximal possible time that stays unchanged until the difference is in the correct range.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-19 09:31:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1066516 | ||
| Bug Blocks: | |||
|
Description
Jan Kurik
2014-03-04 14:11:39 UTC
How to test:
(1) Create an file system with enabled quotas.
(2) Export the file system over NFS and mount the NFS file system.
(3) Set quota limits for a user. Use soft limit lower than hard limit.
(4) Create file large enough to exceed the soft limit.
(5) Set grace time to a slightly more than 60 seconds:
$ setquota -u root -T 60 0 /mnt/quota/
(6) Verify 1 minute of grace time is reported by quota(1) tool on the server and
on the client:
# quota
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 00:01 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 00:01 3 0 0
(7) Wait until the grace time (60 seconds) expires.
(8) Verify that the grace time is reported as `none' on both server and client.
Before:
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 none 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 49697days 3 0 0
After:
# quota
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 none 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 none 3 0 0
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0313.html |