Bug 1066516
| Summary: | Wrong value for expired grace period retrieved over network | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | M.T <tmaria> | ||||||
| Component: | quota | Assignee: | Petr Pisar <ppisar> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.4 | CC: | jorton, 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 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Cause:
Displaying grace time using quota(1) tool for NFS-mounted
file system with enabled disk quotas while the soft quota
limit for current user is exceeded and grace quota time
has already expired.
Consequence:
The `quota' command reports a large number of days
instead of `none'.
Fix:
A misinterpretation of integer type used to transfer
grace times over network has been fixed. In addition,
range of possible values has been limited into 32-bit
signed integer boundaries in order to ensure
interoperability between NFS servers and clients
differing in CPU word size.
Result:
Grace time values whose difference from server time
is in range from -2^31+1 to 2^31 seconds are reported by
quota tools on NFS clients correctly. Other values are
reported as expired or maximal possible time
respectively.
|
Story Points: | --- | ||||||
| Clone Of: | |||||||||
| : | 1067352 1067353 1072769 1072858 (view as bug list) | Environment: | |||||||
| Last Closed: | 2014-10-21 09:05:23 UTC | Type: | Bug | ||||||
| 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: | |||||||||
| Bug Blocks: | 1070830, 1072404 | ||||||||
| Attachments: |
|
||||||||
Thank you for the report. I can reproduce the issue with quota-3.17-21.el6.x86_64. Hello Petr Many thanks for the reply. So we will expect for a new updated version of the quota rpm? Maria I cannot make any promise. However you can increase chance for updating the quota package by contacting Red Hat support. I forwarded the problem the upstream, as all versions of quota tools are affected and there is no bullet-proof solution due to badly designed RPC protocol the quota tools use. Created attachment 867047 [details]
Proposed fix
Posted to upstream for review.
Created attachment 870875 [details]
Proposed fix ported to 3.17
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
This bug was resolved in a RHEL 6.5 errata per bug 1072404. https://rhn.redhat.com/errata/RHBA-2014-0313.html |
Description of problem: Trying to check the quota of a users from an nfs client, (the directory resists on an nfs filesystem), you get a huge value for grace period, instead of none. Version-Release number of selected component (if applicable): RedHat 6.4 How reproducible: Always Steps to Reproduce: 1. Set up an NFS server, with a local filesystem ext4, with quota enabled 2. Run quota -v <username> on nfs server and you get the following output [root@server]# quota -v user1 Disk quotas for user user1 (uid 3059): Filesystem blocks quota limit grace files quota limit grace /dev/mapper/HomeVG-StudentLV 178000 491520 501760 7771 0 0 /dev/mapper/MailVG-MailLV 254548* 244800 256000 none 1104 0 0 3. On an nfs client, that mount the above filesystem (with nfsv4 protocol) if you issue the command quota -v user1, your get a huge number for grace period instead of none [root@nfsclient~]# quota -v user1 Disk quotas for user user1 (uid 3059): Filesystem blocks quota limit grace files quota limit grace csfs9:/mail/ 254548* 244800 256000 49703days 1104 0 0 csfs7:/home/students/ 178000 491520 501760 7771 0 0 Actual results: Expected results: Additional info: The same output can be verified on both redhat linux 5 and 6, with nfs protocol v3 and v4. For users that their grace period has not been expired, you get the correct number of days. The grace period has also been defined on nfs server.Running edquota -t on nfs server you get the output 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/mapper/HomeVG-StudentLV 7days 7days /dev/mapper/MailVG-MailLV 7days 7days