In xfs/299, project IDs are in $tmp.projid file. But there's one
line code try to use $temp.projid. Fortunately, it doesn't bring
any problems until now, but if keep using $temp.projid it really
don't make sense.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Replace every explicit mount/umount of scratch or test devices with
helper functions. This allows the next patch to add in hooks to these
functions in order to set up & tear down overlayfs on every mount/umount
(also adds _test_unmount(), which didn't exist prior)
[Eryu Guan rebased the patch agains latest master and replaced more
mount/umount with helpers]
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eric Sandeen <esandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
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>
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>
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>
Zorro Lang
Eric Sandeen
Dave Chinner
Jie Liu
Chandra Seetharaman