Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 623016 - ext4+dealloc don't update quotas until data written to disk
ext4+dealloc don't update quotas until data written to disk
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Eric Sandeen
Red Hat Kernel QE team
:
Depends On:
Blocks: GSS_6_2_PROPOSED 703492
  Show dependency treegraph
 
Reported: 2010-08-11 02:18 EDT by Lachlan McIlroy
Modified: 2015-04-12 19:14 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-01 11:55:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Lachlan McIlroy 2010-08-11 02:18:08 EDT
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 13:13:26 EDT
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 15:53:18 EDT
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 2011-06-20 05:14:38 EDT
Dear NEC,

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

Best Regards,
Masaki Furuta
Comment 6 Osamu Samukawa 2011-06-30 08:24:30 EDT
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 05:34:35 EDT
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 11:55:21 EDT
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.