With coreutils v8.16 the style of apostrophes changed from `word' to
'word'. This is breaking some tests which use the older form.
This commit introduces function changes the golden output of the
affected tests and introduces a filter for the older style output.
[dchinner: modified to use a global filter in check rather than
per-test filters]
[rjohnston: minor comment change]
Signed-off-by: Tomas Racek <tracek@redhat.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
We were actually testing this improperly, there was a bug in the set default
code so we weren't actually honoring the 0 subvolid properly. To fix this we
need to get the subvolid for the subvol we want to set as the default and use
that in the command. With this patch we now pass again with the fix for the 0
subvolid. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Tested-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Josef noticed that using /dev/zero to generate most of the test
data doesn't work if someone overrides the mount options to
enable compression. The test that performs a cancellation failed
because the replace operation was already finished when the
cancel request was executed.
Since /dev/urandom is too slow to generate multiple GB, the
way how the filesystem data is generated is completely changed
with this patch. Now /dev/urandom is used to generate one 1MB
file and this file is copied up to 2048 times. /dev/zero is no
longer used.
The runtime of the test is about the same as before. Compression
works now, online duplication will again cause issues, but
we don't have online duplication today.
Reported-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Jan Schmidt <list.xfs@jan-o-sch.net>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Otherwise it fails with ENOSPC on CRC enabled filesystems because
of the larger inode size.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The XFS implementation of _scratch_mkfs_sized ignores MKFS_OPTIONS
when a custom block size is set and so isn't testing things like
CRCs on such sized filesytsems. Fix this by ensuring we don't try to
override the block size is it is set in MKFS_OPTIONS. xfs/204 shows
this problem.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Because if it corrupts the filesystem it currently goes undetected.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Turns out btrfs-convert broke on July 3, and lo! we
do not have a regression test, and now we have one,
and there was much rejoicing.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test performs btrfs device replace tests with all possible profiles
(single/dup/mixed/raid0/raid1/raid10), one round with the '-r' option
to 'btrfs replace start' and one round without this option. The
cancelation is tested only once and with the dup/single profile for
metadata/data.
This test takes 181 seconds on my SSD equiped test box and 237s on
spinning disks. Almost all the time is spent when the filesystem is
populated with test data. The replace operation itself takes less than
a second for all the tests, except for the test that is marked as
'thorough' which will run for about 8 seconds on my test box.
The amount of tests done depends on the number of devices in the
SCRATCH_DEV_POOL. For full test coverage, at least 5 devices should
be available (e.g. 5 partitions). With less than 2 entries in
SCRATCH_DEV_POOL, the test is not executed.
The source and target devices for the replace operation are arbitrarily
chosen out of SCRATCH_DEV_POOl. Since the target device mustn't be
smaller than the source device, the requirement for this test is that
all devices have _exactly_ the same size. If this is not the case, the
test terminates with _notrun.
To check the filesystems after replacing a device, a scrub run is
performed, a btrfsck run, and finally the filesystem is remounted.
This commit depends on my other commit:
"xfstest: don't remove the two first devices from SCRATCH_DEV_POOL"
[rjohnston: renumbered to btrfs/011]
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
One problem was the output of "uniq -c" which added spaces depending
on the size of the count value (e.g. one space less for 10+ devices).
The second problem was that "btrfs fi show" was doing the same:
"devid %4llu size %s used %s path %s".
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Since common/config is executed twice, if SCRATCH_DEV_POOL is configured
via the environment, the current code removes the first device entry twice
which means that you lose the second device for the test.
The fix is to not remove anything from SCRATCH_DEV_POOL anymore.
That used to be done (I can only guess) to allow to pass the
SCRATCH_DEV_POOL as an argument to _scratch_mkfs. Since _scratch_mkfs adds
the SCRATCH_DEV, the pool mustn't contain that device anymore.
A new function _scratch_pool_mkfs is introduced that does the expected
thing.
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.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>
This is to test whether snapshot-aware defrag can work well on partial extents.
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test failed for me with output from 'btrfs balance':
QA output created by 003
+Done, had to relocate 4 out of 4 chunks
+Done, had to relocate 5 out of 5 chunks
Silence is golden
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
After applied this commit (864688d3), xfstests #255 will not test a
file system that cannot support fallocate(2), such as a indirect-based
file in ext4. So we need to add a new generic test case to test it.
The difference between #255 and this test case is only to use pwrite to
allocate blocks. Other filesystems should survive in this test case.
In the mean time, a new argument '-u' is added into _test_generic_punch
not to run unwritten tests.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: xfstests: make the scratch device for generic/256 slightly larger
Date: Tue, 02 Jul 2013 19:17:18 -0000
From: Josef Bacik <jbacik@fusionio.com>
X-Patchwork-Id: 5816
Message-Id: <1372792638-23957-1-git-send-email-jbacik@fusionio.com>
To: <linux-btrfs@vger.kernel.org>, <xfs@oss.sgi.com>
This is similar to a previous fix I sent. 1 gig makes us do mixed file block
groups for btrfs, so these enospc tests will usually fail because we don't have
space for metadata, which is the case for this test. So jack the size up to
1.5gig so that btrfs can do its normal thing and pass the test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston: renumbered test from 003 to 009]
This is a regression test for a problem we had where we'd assume we had created
a directory if it only had subvols inside of it. This was happening because
subvols would have lower inode numbers than our current send progress because
their inode numbers are based off of a different counter. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston: renumbered test from 002 to 008]
Basic send / receive functionality test for btrfs. Requires current
version of fsstress built (-x support). Relies on fssum tool but can
skip the test if it failed to build.
Signed-off-by: Jan Schmidt <list.xfs@jan-o-sch.net>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
[rjohnston: renumbered test from 316 to 007]
Current numbering is inheried from the single testsuite series. There
are only 6 btrfs-specific tests and it makes more sense to start adding
new ones at a more natural place than 300-something. There's no overlap
with the old and new numbers and I hope there' will be no confusion when
referencing them.
Signed-off-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
So df in btrfs is tricky at best, and relying on it for accurate information is
not great, but it's the best way to verify this test. To get around btrfs being
inconsistent sometimes just use _within_tolerance to check our new df value to
make sure that our truncate did something. With this patch I no longer see
transient failures of this test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Jie Liu <jeff.liu@oracle.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
ls -l will show the nblocks for the directory, and this made it into the golden
output for 314. The problem is nblocks is 0 for btrfs directories because we're
awesome, which makes us fail this test. So filter out the "total blah" line of
ls -l so btrfs can pass this test too. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Introduce generic test 315 to verify if the disk space is
released after truncating a preallocated file back to the
old smaller size. Before Linux-3.10, Btrfs/OCFS2 test
failed in this case.
The test file is fallocated with FALLOC_FL_KEEP_SIZE option.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Tomas Racek
Josef Bacik
Stefan Behrens
Dave Chinner
Eric Sandeen
Chandra Seetharaman
Liu Bo
Dwight Engen
Zheng Liu
Jan Schmidt
David Sterba
Jie Liu