Commit Graph

5 Commits

Author SHA1 Message Date
Chandan Rajendra dac07d0816 xfs/299: work with 64k block size
This commit changes the test to calculate quota limits based on the
block size of the underlying filesystem. Also, the sizes of the test
files are now made to be a multiple of the filesystem block size.

Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-09-30 13:57:50 +08:00
Chandan Rajendra 8758c0065f xfs/299: Fix "Push past soft inode limit" case
The test sets an inode soft limit of four but only three files are
created. This commit creates two more files in order to really push past
the soft inode limit.

Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Tested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-09-30 13:57:50 +08:00
Dave Chinner 47dbcf13f7 xfs/299: users can't modify root owned files
xfs/299 has failed for me for a long time. In fact, looking at my
logs it has never passed on any of my test machines. IOWs, the
test that was committed was fundamentally broken.

The reason is that it tests project quotas before it tests user or
group quotas and so creates a bunch of files that are owned by root
or privileged users. It think tries to manipulate them as a user,
and, unsurprisingly, it fails to do so. This then causes the test to
throw an error.

The reason it has always failed is the error that is thrown
hardcodes a uid/gid into an error message. This uid/gid is what
causes the golden output mismatch (nobody is 65534 on my machines,
not 99):

     *** push past the hard block limit (expect EDQUOT)
     [ROOT] 0 0 0 00 [--------] 12 0 0 00 [--------] 0 0 0 00 [--------]
     [NAME] =OK= 100 500 00 [--------] 7 4 10 00 [7 days] 0 0 0 00 [--------]
    - URK 99: 0 is out of range! [425,500]
    + URK 65534: 0 is out of range! [425,500]

It wasn't until I looked at the xfs/299.full file when trying to
understand why the error was being thrown and whether it shoul dhave
been in the golden output in the first place that I saw the real
problem. That is, All the user/group quota modifications were
failing because of not having permissions to write the files left
behind by the quota test, and that user and group quotas were not
being tested at all by the test.

So, firstly $SCRATCH_MNT needs to be world writeable, and secondly
each test needs to remove the files it created during the test so
they don't impact on furture test iterations.

This then exercises the user and group quotas appropriately, and so
the golden output changes completely to reflect that changes under
user quotas are actually being accounted to the correct user.
Further, the error message that I originally saw errors on goes
away, because everything is now accounted correctly.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-02-18 17:16:26 +11:00
Jie Liu cc92a9531f xfs: refactor xfs/299 for crc feature pre-checkup
Refactor xfs/299 to make use of those two crc related pre-checkup
routines, and remove the super block number from the golden output
file as it does not make sense IMO.  Also, filter out *EXPERIMENTAL*
string from mkfs.xfs output as those contents would be removed once
crc feature becomes stable.

Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-01-20 12:44:02 +11:00
Chandra Seetharaman 385f466a3d xfstests: Test all 3 quotas simultaneously.
Add a test for testing all 3 (user, group and project) quotas together.

This is a modified version of xfstest 050.

Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
2013-08-27 12:09:12 -05:00