Btrfs will default to mixed block groups for 1 gigabyte file systems and
smaller, which means data and metadata share the same area. This makes
generic/274 fail for us because we cannot reserve enough metadata space to do
our writes. Bumping the scratch fs up to 2 gigabytes allows us to do our normal
metadata/data separation and allows us to pass this test. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test is motivated by an issue found by a btrfs user, addressed
and described by the following Linux kernel patch:
https://patchwork.kernel.org/patch/3046931/
The steps to reproduce the issue on btrfs are the following:
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt
$ mkdir /mnt/acl
$ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl
$ getfacl /mnt/acl
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::---
$ mkdir /mnt/acl/dir1
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
After unmounting and mounting again the filesystem, getfacl returned the
expected default ACL for the subdirectory:
$ umount /mnt/acl
$ mount /dev/loop0 /mnt
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
This means that the underlying ACL xattr was persisted correctly but
the in memory representation of the inode had (incorrectly) a NULL ACL.
[rjohnston: renumbered test to 319]
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
test xfs/205 expects a certain log size, but defaults have
changed, the logs are bigger, and this test now fails w/ early
ENOSPC:
QA output created by 205
+ !!! disk full (expected)
+ !!! disk full (expected)
+ !!! disk full (expected)
*** one file
+ !!! disk full (expected)
*** one file, a few bytes at a time
...
Fix this by specifying the log size at mkfs time, so freespace is
as the test expects it to be.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Originally, when executing "btrfs balance" right after
"btrfs subvolume snaphot" & "btrfs subvolume delete",
a kernel BUG arises.
This problem is caused by the patch:
[PATCH 1/2] Btrfs: fix for patch "cleanup: don't check
the same thing twice"
The commit id: 48475471728f060bfd2e686f592ef208d3ba8b7d
(in kernel/git/torvalds/linux.git)
handled by the patch:
[PATCH 2/3] Btrfs: fix oops caused by the space balance
and dead roots
[rjohnston: change test number to 14]
Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Long device names may be split onto their own line
on quota output:
Filesystem Blocks Quota Limit Warn/Time Mounted on
/dev/mapper/my-very-very-very-long-devicename
48M 0 0 00 [------] /mnt/scratch
which breaks tests that capture quota output - currently,
only xfs/108.
Add a _filter_quota() which fixes this.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
The mount binary changed its output w.r.t. red-only devices, and
stopped referring to a "block device."
This broke at least test xfs/200; add a common filter to remove
the "block device" from older mount binary output, and change
the 200.out file to match.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
test 294 is using the scratch device w/o mkfs-ing it first,
this runs the risk of following a test which completely
fills the fs, causing 294 to fail.
add "rm -f $seqres.full" as well, it was growing on every run.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Test 259 tries to make a loop device size which is 1 byte less
than 4T; losetup now warns that this makes little sense, and
the warning breaks the test output:
+losetup: /mnt/test/259.image: warning: file does not fit into a 512-byte sector the end of the file will be ignored.
The RH QE testcase did originally use loopback, so did
not in effect test anything other than 512-multiple boundaries.
Just drop the non-512-byte-multiple cases, they produce
devices exactly the same size as their 512-byte-multiple
neighbors.
(FWIW, this is a regression test for the bug that
d943b11 mkfs: get size of device properly
fixed.)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Starting from util-linux v2.23 fstrim(1) reports trimmed bytes
differently, e.g.
new fstrim: /mnt/ext4: 9.7 GiB (10411118592 bytes) trimmed
old fstrim: /mnt/ext4: 10411118592 bytes were trimmed
generic/260 reports syntax error
+./tests/generic/260: line 111: [: 9.7: integer expression expected
+./tests/generic/260: line 121: [: 9.7: integer expression expected
+./tests/generic/260: line 183: [: 9.7: integer expression expected
Add a new filter called _filter_fstrim in common/filter and get the
correct trimmed bytes in generic/260, so the test passes with both old
and new fstrim.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
We had a regression where we were not copying csums properly when balancing a
prealloc extent. Unfortunately the way this showed up the most was with the
csum simply missing, which doesn't result in an error to userspace. So I've
copied what generic/310 does and check dmesg for csum errors when the test
starts and then compare that count to the csum errors after the test finishes to
see if there was a problem. This approach caught the error without my fix, and
then passed fine with my fix in place but with the previous errors still in
dmesg. Thanks,
[rjohnston: changed test number to 13]
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
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>
Josef Bacik
Filipe David Borba Manana
Eric Sandeen
Gui Hecheng
Eric Sandeen
Eryu Guan
Tomas Racek
Stefan Behrens
Dave Chinner
Chandra Seetharaman
Liu Bo
Dwight Engen