Bug 688862

Summary: [ext4/xfstests 219]: repquota reports too big used size
Product: Red Hat Enterprise Linux 6 Reporter: Eryu Guan <eguan>
Component: kernelAssignee: Eric Sandeen <esandeen>
Status: CLOSED NOTABUG QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 6.1CC: branto, esandeen, gbeshers, gbeshers, lczerner, rwheeler
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 662025 Environment:
Last Closed: 2012-02-19 15:14:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 662025    
Bug Blocks:    

Description Eryu Guan 2011-03-18 10:02:08 UTC
This also happens on ext4 on RHEL6
Kernel version 2.6.32-122
quota-3.17-14

Here are two failed jobs
https://beaker.engineering.redhat.com/recipes/128693
http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2011/03/627/62751/128693/1409547/5403376///test_log--kernel-filesystems-xfs-xfstests-219.log

https://beaker.engineering.redhat.com/recipes/128682
http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2011/03/627/62751/128682/1409514/5401932///test_log--kernel-filesystems-xfs-xfstests-219.log

+++ This bug was initially created as a clone of Bug #662025 +++

Description of problem:
Test cases 219 and 235 fail because repquota reports too big used size on ext3 filesystem in rhel5.

Version-Release number of selected component (if applicable):
kernel-2.6.18-235.el5

How reproducible:
Always

Steps to Reproduce:
1. Run tests 219 and 235 for ext3 filesystem:
TEST_PARAM_RUNTESTS="219 235" TEST_PARAM_FSTYPE="ext3" make
2. Watch the output
  
Actual results:
Both tests fail because the different used size.

Expected results:
Both tests pass.

Additional info:
Related outputs from beaker:
http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2010/12/371/37178/74127/832713/2624000///test_log--kernel-filesystems-xfs-xfstests-219.log
https://beaker.engineering.redhat.com/logs/2010/12/359/35945/71034/796863/2499979///test_log--kernel-filesystems-xfs-xfstests-235.log

Comment 2 Eric Sandeen 2011-03-18 17:39:05 UTC
The test writes 48k to 3 different files.  This creates 147456 bytes of usage, or 144 1k blocks.  So 144 is right but we get 148:

                         Block limits                File limits
 Group           used    soft    hard  grace    used  soft  hard  grace
 ----------------------------------------------------------------------
-#2        --     144       0       0              3     0     0       
+#2        --     148       0       0              3     0     0      

IOW, 4k extra.

All I can think is that this is an xattr block or something, but the fs is supposed to be mounted with a context, and not create selinux xattrs.

I am unable to repro this on rhel6, but I can repro it on rhel5.

And there is indeed an xattr block created:

# debugfs /dev/sdb3 
debugfs 1.39 (29-May-2006)
debugfs:  stat buffer
Inode: 14   Type: regular    Mode:  0644   Flags: 0x0   Generation: 1873143472
User:     1   Group:     2   Size: 49152
File ACL: 17160    Directory ACL: 0
Links: 1   Blockcount: 104
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x4d839b16 -- Fri Mar 18 12:49:10 2011
atime: 0x4d839b16 -- Fri Mar 18 12:49:10 2011
mtime: 0x4d839b16 -- Fri Mar 18 12:49:10 2011
BLOCKS:
(0-11):26636-26647
TOTAL: 12

and it's shared on all 3 files:

debugfs:  stat direct
Inode: 15   Type: regular    Mode:  0644   Flags: 0x0   Generation: 1873143473
User:     1   Group:     2   Size: 49152
File ACL: 17160    Directory ACL: 0
...

debugfs:  stat mmap
Inode: 16   Type: regular    Mode:  0644   Flags: 0x0   Generation: 1873143474
User:     1   Group:     2   Size: 49152
File ACL: 17160    Directory ACL: 0
...

so that's the issue.

after running the test we can look at dmesg:

# dmesg | grep ext3
SELinux: initialized (dev sdb3, type ext3), uses mountpoint labeling
SELinux: initialized (dev sdb2, type ext3), uses xattr
SELinux: initialized (dev sdb3, type ext3), uses xattr
SELinux: initialized (dev sdb3, type ext3), uses xattr
SELinux: initialized (dev sdb3, type ext3), uses xattr
SELinux: initialized (dev sdb2, type ext3), uses xattr

and see that while the test was run, it didn't pick up the mountpoint labeling.

This is just a test flaw, I think, not a quota problem.  (odd that it doesn't fail for me on rhel6 though, because it also doesn't mount with the context during the test ...)

Comment 3 RHEL Program Management 2011-04-04 02:25:40 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 4 RHEL Program Management 2011-10-07 15:27:13 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 5 Eric Sandeen 2012-02-17 22:31:19 UTC
I think that this was an xfstests bug, fixed by:

commit 7f4a2e30b263fc301b2edd5a8f4abf66e7b3d4dc
Author: Jan Kara <jack>
Date:   Wed Jun 29 16:04:40 2011 +0000

    xfstests: Improve test 219 to work with different filesystems
    
    Different filesystems account different amount of metadata in quota.
    Thus it is impractical to check for a particular amount of space
    occupied by a file because there is no right value. Change the test
    to verify whether the amount of space is between the expected amount
    of space and the expected amount +5%.  The number of files is
    checked exactly as previously.
    
    Signed-off-by: Jan Kara <jack>
    Signed-off-by: Alex Elder <aelder>


Can you confirm that it's no longer a problem?

Thanks,
-Eric

Comment 6 Eryu Guan 2012-02-19 15:14:07 UTC
219 passes on ext4 with all block sizes now.

Close it as NOTABUG.