Bug 145504
| Summary: | Quota and Repquota commands not updating | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Brown <daveb21> |
| Component: | quota | Assignee: | Chris Feist <cfeist> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | CC: | cfeist, kanderso, steved |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-02-08 05:54:42 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: | |||
Can someone please change priority on this bug to high, unfortunately when i try to do it bugzilla tells me i don't have the access (even though i am the bug submitter). Are you running 'quotaon -a' or 'quotaon /filesystem' as part of your bootup process? Also, can you post the output of the 'quotaoff -a' command. My apologies, we are using Linuxha to mount the partititions and I have just found that it doesnt turn on quotas on the filesystem when you mount it (even if you tell it to mount using usrquota or grpquota options). I have had to write a short script for linuxha to actually turn quota on when it brings up its resources. Am closing the bug. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Description of problem: Output of repquota and quota commands not updating in real time. System is running Fedora Core 2 with 1 LVM Physical Volume and 2 LVM logical volumes. An ext3 filesystem is created on each Logical volume and usrquota is specified in mount options (grpquota not specified nor required). Volumes are 300Gb and 383Gb (approx) in size. Physical volume is actually a RAID5 set (although i think this shouldn't matter). User / shadow / group information stored in LDAP and approx 20000 users in directory (although will grow to about 200,000). Version-Release number of selected component (if applicable): quota-3.10-2 How reproducible: Always Steps to Reproduce: 1.Create user either in LDAP or using useradd. 2.setquota -u username 10000 10000 0 0 /partition 3.chown username:username /partition/file 4.quota -uv username Actual Results: quota -uv returns Disk quotas for user username (uid 200): Filesystem blocks quota limit grace files quota limit grace /dev/mapper/lvg-partition 0 10000 10000 0 0 0 Expected Results: quota -uv should return Disk quotas for user username (uid 200): Filesystem blocks quota limit grace files quota limit grace /dev/mapper/lvg-partition filesize 10000 10000 0 0 0 Additional info: Once a quotacheck -avum is run on the filesystem the reported blocksize is correct, however the reported size is not updated "on the fly". It only updates after a quotacheck. This size should update on every write to disk for the affected user.