Bug 623016
Summary: | ext4+dealloc don't update quotas until data written to disk | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Lachlan McIlroy <lmcilroy> | ||||
Component: | kernel | Assignee: | Eric Sandeen <esandeen> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6.0 | CC: | esandeen, jwest, mfuruta, redhat-bz, samukawa-oxa, vgaikwad | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-07-01 15:55:21 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: | |||||||
Bug Blocks: | 658636, 703492 | ||||||
Attachments: |
|
This behavior persists upstream, at least as recently as 2.6.39. To be honest, I have to re-remember when delalloc data is supposed to be visible to quota, by design... Quota is enforced even if not shown; adding setquota to the script does: # first repquota (quotausr doesn't use blocks) Block limits File limits User used soft hard grace used soft hard grace quotausr -- 0 10000 10000 1 0 0 dd: writing `/mnt/mp1/file': Disk quota exceeded 1+0 records in 0+0 records out 10240000 bytes (10 MB) copied, 0.0639514 s, 160 MB/s # second repquota (quotausr uses some blocks but repquota doesn't report it) Block limits File limits User used soft hard grace used soft hard grace quotausr -- 0 10000 10000 1 0 0 It does seem like it should be properly reported, I'll look into it. -Eric I talked with Jan Kara about this. I said: > repquota doesn't show us "reserved" space for delayed allocations. > I guess this is because repquota reads the quota file itself, which > doesn't know about reservations? > Is this just the way the design is? and Jan said: > Exactly. Quota file contains only information about persistently stored > data. > Well, not exactly by design but more a consequence of repquota(8) lacking > proper kernel interface. Thus the tool has to provide the functionality by > reading quota file which has its limitations. Workaround would be to do > sync(1) before running repquota... In other words, this is not a bug per se; it is more of an issue with the current quota infrastructure. Note that quota -is- still enforced for the delayed allocations; it just isn't shown in the quotafile, and therefore not in repquota output. So this will take a currently-unknown quantity of new work upstream to resolve. How urgent is this? Dear NEC, As per comment 4, Would you please provide your concern? Best Regards, Masaki Furuta Furuta-san,
>>>> As per comment 4, Would you please provide your concern?
>>
>> The serious problem on the practical use by occurrance of this problem is none,
>> as the urgency is not high.
We understood that this issue is difficult and will take time to fix.
I will close this ticket for now.
But if some customer appears who strongly request this to be fixed,
we may re-open this ticket in the future.
What should be the resolution for this bug? WONTFIX does not seem preferable because this might be reopened if business impact increases. Maybe NOTABUG, or INSUFFICIENT DATA? UPSTREAM might be reasonable. The current behavior is the upstream design, and it's working as intended, although we recognize the shortcomings. It'd need to be designed and implemented upstream first... |
Created attachment 438083 [details] Reproducer script Description of problem: When filesystem is made in ext4 after user quota or group quota is enabled, the used number of blocks were not immediately be reflected the result outputed by the repquota command. But this problem is canceled when sync command is run, or wait for 60 seconds. Version-Release number of selected component (if applicable): RHEL6 Snapshot8 (2.6.32-52.el6.x86_64) How reproducible: always Steps to Reproduce: 1. Install RHEL6 2. Boot RHEL6 3. Run get_quota_limits.sh attached on this BZ as follows. # ./get_quota_limit.sh Actual results: Used number of blocks won't be immediately reflected to the result outputed by the repquota command. # ./get_quota_limit.sh # first repquota (quotausr doesn't use blocks) Block limits File limits User used soft hard grace used soft hard grace quotausr -- 0 0 0 1 0 0 # second repquota (quotausr uses some blocks but repquota doesn't report it) Block limits File limits User used soft hard grace used soft hard grace quotausr -- 0 0 0 1 0 0 # third repquota (quotausr uses some blocks and repquota reports it) Block limits File limits User used soft hard grace used soft hard grace quotausr -- 10240 0 0 1 0 Expected results: The value of "used" on block limits is 10240 when repquota command runs for the second time. Additional info: - This problem does not occur in ext3 - The same problem also occurs by grpquota command. - This problem will not occur if "-o nodelalloc" option is added when filesystem is mounted ext4. - This problem also occurs on RHEL6 Snapshot9.