RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 623016 - ext4+dealloc don't update quotas until data written to disk
Summary: ext4+dealloc don't update quotas until data written to disk
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: GSS_6_2_PROPOSED 703492
TreeView+ depends on / blocked
 
Reported: 2010-08-11 06:18 UTC by Lachlan McIlroy
Modified: 2018-11-14 18:47 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-01 15:55:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Reproducer script (1.57 KB, application/x-shellscript)
2010-08-11 06:18 UTC, Lachlan McIlroy 		no flags Details
View All

Description Lachlan McIlroy 2010-08-11 06:18:08 UTC 
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.
Comment 3 Eric Sandeen 2011-06-08 17:13:26 UTC 
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
Comment 4 Eric Sandeen 2011-06-13 19:53:18 UTC 
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?
Comment 5 Masaki Furuta ( RH ) 2011-06-20 09:14:38 UTC 
Dear NEC,

As per comment 4, Would you please provide your concern?

Best Regards,
Masaki Furuta
Comment 6 Osamu Samukawa 2011-06-30 12:24:30 UTC 
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.
Comment 7 Osamu Samukawa 2011-07-01 09:34:35 UTC 
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?
Comment 8 Eric Sandeen 2011-07-01 15:55:21 UTC 
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...
Note You need to log in before you can comment on or make changes to this bug.