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>
Test generic/192 fails if noatime is set
generic/192
-delta1 - access time after sleep in-core: 40
-delta2 - access time after sleep on-disk: 40
+delta1 - access time after sleep in-core: 0
+delta2 - access time after sleep on-disk: 0
but it's pointless to test atime effects with noatime.
Signed-off-by: David Sterba <dsterba@suse.cz>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Tests if subdirectories created on the filesystem will properly inherit sgid bit
when this is set on the parent directory, once the process has the properly
permissions to create a subdirectory, this, should inherit parent's sgid bit if
this is set and irix_sgid_inherit sysctl is disabled.
V2: add missing source of "attr" file for _require_acls
V3: use _ls_l to filter out the selinux "."
renumber to 314 to make the merge easier
V4: fix 314.out to the correct output
Thanks to Sandeen who have written this patch
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Tests the XFS symlinks that are small enough to be in the
inode, but were move to a remote symlink due to an extended
attribute were correctly removed.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Regression test for commit:
3972f26 btrfs: update timestamps on truncate()
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
It was missed when converting all the tests as it was using
${seq}.full and none of the regexes matched it. Fix it up to direct
the output to the correct place.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
generic/193 runs the test in $here - the root of the xfstests source
tree/installation. IOWs, it doesn't test the filesystem on either
the TEST_DIR or SCRATCH_MNT, and so it not testing the filesystem
we think it is testing. Bad. Fixing this is the majority of the
change - introducing $test_root and $test_user for the files with
different owners, and then redirecting error output and filtering
the output appropriately.
And then add checks that truncate clears the suid/sgid bits
appropriately, something that has never been tested on XFS (and
likely other filesystems) so will cause kernels between 3.1 and 3.9
to assert fail as Dave Jones has recently reported.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
In some configurations (e.g. 1 KB block size), ext4 can decide it is
better to zero out several blocks rather than splitting unwritten
extent. This changes results SEEK_HOLE / SEEK_DATA returns and thus the
test fails. Fix the problem by disabling the feature for this test.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The generic/286 test tests SEEK_HOLE and SEEK_DATA, and is reasonably
fast. We should just run the test by default.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Use the built-in _test_mount function from xfstests so it will use
the correct mount options for xfstests. The script used a simple
umount-and-mount sequence, which caused a test failure on an XFS
filesystem that used both realtime and external log devices.
Signed-off-by: Michael L. Semon <mlsemon35@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@rehat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
xfs was having issues with generic/311 because of caching issues. Make
_check_scratch_fs take an optional argument to use as the device to fsck.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Acked-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Now in tests/ there are some test cases whose mode is 0644. But they
should be 0755. So fix it.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Dave Chinner <david@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
test 284 had... some issues.
First, it took so long nobody ran it; so shorten the extent
count by a factor of about 100.
Having fixed that, we see failures in 2 cases; when start or
len is -1, but the golden output file didn't have error
output, as if they should pass.
I'm going to argue that these *should* both fail; start = -1
has no real meaning. length = -1 might mean "the rest
of the file" but if that's what you really want, just
don't specify -l.
So add failure output for those cases.
Send all command output to $seq.full, in case that changes
in the future; just capture the return value.
Then remove the return value echo on failure (50?) because
who knows when that might change to some other magic value.
Ok, then when defrag actually works, old defrag returned
"20" (because?) but a recent commit changed it to 0.
So accommodate that too.
And remove a stray "HAVE_DEFRAG=1" while we're at it.
That variable is never used.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
supports seek data/hole operation or not. Here _require_seek_data_hole
is defined to do this work.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Reviewed-by: Rich Johnston <rjohnston@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>