Different quota format may print additional information in
repquota(8) output after standard quota information is printed. If
format does support this additional printouts, repquota(8) will
separate possible output by two empty lines even if format handler
doesn't actually printout anything (which is currently always the
case for queries test generic/235 does). If format doesn't support
additional printouts, these two empty lines are not present in the
output. This inconsistency causes false failures for some quota
formats.
Fix the problem by filtering out empty lines out of repquota(8)
output.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Update the following quick/auto tag based on their execution time
btrfs/007
btrfs/050
btrfs/100
btrfs/101
Two systems are used to determine their execution time. One is
backed by an SATA spinning rust, whose maximum R/W speed is about
100MB/s, modern desktop performance. (VM1)
Another one is a VM inside a openstack pool, with stronger CPU and
memory performance along with high latency storage. Maximum R/W
speed is around 150MB/s, latency is much higher than normal HDD
though. (VM2)
The 'quick' standard is a little more restrict, only when both
systems pass the test within 30s(+/- 10%), while 'auto' is less
restrict, any system can pass within 5min(+/- 10%) will still stay
in 'auto' group.
Other test cases don't fit both standards on both systems will not
be modified.
Execution time result: (Unit: seconds)
------------------------------------------------------
Test case No. | VM1 | VM2 | Modification |
------------------------------------------------------
btrfs/007 | 4 | 2 | +quick |
btrfs/050 | 4 | 13 | +quick |
btrfs/100 | 57 | 151 | -quick |
btrfs/101 | 45 | 59 | -quick |
------------------------------------------------------
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On my test setup xfs_io reports 'nan' in bytes/s and ops/s fields
when the operation takes zero time. Account for that in
_filter_xfs_io.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Really old versions of coreutils (mine are 8.12) quote a filename in the
output with a backquote in the beginning and normal quote in the end.
Improve _filter_mknod to handle that.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When fsx fails we try to copy failure state to the results/
dir, but in some cases we are using $seqres instead of
$seq or $seq instead of $here/$seq; fix this up so the
failure state is accurately captured in the results/ dir.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
For fully deduped file, whose file extents are all pointing to the
same extent, btrfs backref walk can be very time consuming, long
enough to trigger softlock.
Unfortunately, btrfs send is one of the caller of such backref walk
under an O(n) loop, making the total time complexity to O(n^3) or
more.
And even worse, btrfs send will allocate memory in such loop, to
trigger OOM on system with small memory(<4G).
This test case will check if btrfs send will cause these problems.
Reporeted-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs/083 will corrupt the fs intentionally, there will be WARNINGs
in dmesg as expected, so here disable dmesg check.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
mkfs.xfs does not do a very good job of input validation. This test
is designed to exercise the input validation and test good/bad
combinations of options being set. It will not pass on an old
mkfs.xfs binary - it is designed to be the test case for an input
validation cleanup (merged in spring/summer 2016).
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
After the previous patch moved few lines of code, one seqnum
assignment is now immediately overwritten by another. Remove the
useless one.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The code handling "./check foo/123", when the real test is
"foo/123-bar-baz" was moved to the earliest position, so everything
working with the test name or path will know the full name. Thus, no
"123" and "123-bar-baz" mix is possible.
An example of this issue is $testname.notrun file. When _notrun
"foo" was run during ./check foo/$name command, it created
$name.notrun. But few lines later, it wanted $fullname.notrun. So if
you did ./check foo/999, but the file was 999-bar-baz, then you got
comparing outputs (and most likely a fail) instead of a skip.
Another example of this mix is in xfstests output:
./check xfs/999
[...]
xfs/999 0s ... 0s
Ran: xfs/999-test-case
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfstests supports extended test names like 314-foo-bar, but
installation of these tests was skipped (not matching a regexp). So
this patch fixes the makefiles in tests/*/
The include/buildrules change was written by Dave Chinner.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
006 and 007 are in reverse order, and this breaks tools to find the
next available seq number in group file (e.g. tools/nextid).
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
In recent mkfs.xfs updates in xfsprogs, commit 9090e187bc3e ("mkfs:
add respecification detection to generic parsing") added
re-specification detection to "-m" option, it causes several tests
_notrun if MKFS_OPTIONS has the same options as those being tested
in _scratch_mkfs_xfs_supported(), because they're specified multiple
times.
MKFS_OPTIONS="-m crc=0" ./check xfs/001
xfs/001 3s ... [not run] mkfs.xfs doesn't have crc feature
Fix it by creating XFS again without MKFS_OPTIONS in
_scratch_mkfs_xfs_supported(), in case there's conflict between
MKFS_OPTIONS and mkfs_opts, like what we do in _scratch_mkfs_xfs().
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
generic/067 mounts $SCRATCH_DEV directly in the test, assuming it's
a block device. generic/299 and generic/300 query the size of
$SCRATCH_DEV by running 'blockdev --getsz $SCRATCH_DEV'.
So add the check to make sure $SCRATCH_DEV is a real block device in
these tests.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Because we recently changed how mkfs behaves when it gets
incorrect/invalid values, add a feature check to run this test only
on older binaries, which accepts invalid sunit values.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a simple way to skip a test if it is (or is not) run on mkfs
correctly validating inputs.
Signed-off-by: Jan Tulak <jtulak@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation does not prematurely issues
rmdir operations under a particular scenario (the rmdir operation is
sent before the target directory is empty).
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix premature rmdir operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that, under a particular scenario, an incremental send
operation does not leak memory (which used to emit a warning in
dmesg/syslog).
This is a regression test for a btrfs kernel fix that has the title:
"Btrfs: send, fix warning due to late freeing of orphan_dir_info
structures".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works after doing radical
changes in the directory hierarchy that involve switching the inode
that directory entries point to.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: send, fix failure to move directories with the same name around"
"Btrfs: incremental send, fix invalid paths for rename operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Wrong value is passed to _require_fs_space, which should be in unit
of kilobyte(1024), but passed in unit of gigabyte(1024^3).
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
An ext4 file system can be created without a journal, but ext4/021
presumes it will contain one. Make that requirement explicit to
avoid unnecessary failures when testing "nojournal" file systems.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Jan Kara
Qu Wenruo
Eric Sandeen
Xiao Yang
Jan Tulak
Christoph Hellwig
Eryu Guan
Filipe Manana
Eric Whitney
Darrick J. Wong