Make sure that we can handle multiple bmbt records mapping to a
single rmapbt record. This can happen if you fallocate more than
2^21 contiguous blocks to a file.
(Also add some helpers that can create huge devices with some
dm-zero and dm-snapshot fakery.)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Since none of the current filesystems support reflinked swap files,
make sure that we prohibit reflinking of swapfiles and swapon of
reflinked files.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Ensure that refcountbt allocations during truncate operations come
from the per-AG reservation and are not charged to the transaction.
Reported-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If we're doing write/overwrite/snapshot/resource exhaustion tests on
the scratch device, use the test directory to hold the loop
termination signal files. This way we don't run infinitely because
we can't create the flag due to ENOSPC.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Adapt to different metadata overhead sizes by trying to reserve
decreasing amounts of disk space until we actually succeed at it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Current port selection algorithm is bound to have port clashes. To
eliminate clashes, let server pick an unused port and report it on
stdout.
Signed-off-by: Tahsin Erdogan <tahsin@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
A comment in shared/272 claims that ext4 supports O_DIRECT in
data=journalling mode. Actually, it doesn't, it was just silently
ignoring O_DIRECT, let's not try to test O_DIRECT for either ext3 or
ext4 in this test.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Commit 902223bdbb: "defrag: require extents support for ext4
defrag" added a test to make sure the ext4 file system has extents
enabled by testing the scratch device. Unfortunately at the time
when _require_defrag is run, the scratch file system hasn't been
initialized yet by the test, so its contents are undefined.
If the previous test explicitly creates a file system with extents
disabled on $SCRATCH_DEV (such as ext4/306), then subsequent tests
(e.g., ext4/307 and ext4/306) will refuse to run.
Fix this by testing $TEST_DEV instead of $SCRATCH_DEV.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There is not i variable in scope, and the comments suggest the
operation is to be done on ${file}.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS had a bug in the multi-block buffer logging code that caused a
NULL lv panic at log push time due to invalid regions being set in
the buffer log format bitmap. This was demonstrated by modifying a
multi-block directory buffer in a manner that only logs regions
beyond the first FSB-sized mapping of the buffer.
To recreate these conditions, this test fragments free space and
populates several directories with enough entries to require
discontiguous multi-block buffers. To recreate the problem, we
remove entries from the tail end of the directory and fsync to flush
the log.
Note that this test causes a panic on kernels affected by the bug.
As such, it is included in the 'dangerous' group. The bug is
resolved by kernel commit a3916e528b91 ("xfs: fix broken multi-fsb
buffer logging").
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test runs quickly and covers code not covered by any other test,
so add it to the quick group. Also add it to the rw group while
we're at it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check that suid/sgid bits are cleared on direct write. XFS triggered
WARN_ON_ONCE in this case. Patchset from Jan Kara fixed the warning:
http://oss.sgi.com/archives/xfs/2014-12/msg00071.html
This test is inspired by a test case from Eric Sandeen, and follows
the test steps in generic/193. This test requires direct I/O, it's
not added to generic/193 but to a new test, so that generic/193
still runs on filesystems don't have direct I/O support.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When testing with data=journal ext4, direct write to dmerror device
doesn't return EIO, because ext4 turns direct write to buffered
write in data=journal mode and all data is written to journal
buffer. The write only fails later when commiting journal and error
messages can be seen in dmesg.
As the test is checking on the md5 checksum of the test file, it's
ok to ignore the IO error returned by xfs_io, as long as the
checksums match the golden image.
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Several golden outputs have:
> Note - stripe unit (0) and width (0) fields have been reset.
but it's entirely possible for this to be non-zero,
which then fails to match and fails the test.
Filter this repair output and fix the golden files.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The $param can't be used for all command's options, for example
"help pwrite" include:
-Z N -- zeed the random number generator (used when writing randomly)
(heh, zorry, the -s/-S arguments were already in use in pwrite)
We should make param="-Z N", not only "-Z". After this patch, we can
run this function as:
_require_xfs_io_command pwrite -Z N
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test handling of private file mappings in the kernel. Check that
writes of only one thread / process are seen in each page and that
none of these make it into the original file.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test case will check SHARED flag returned by fiemap ioctl on
reflinked files before and after sync.
Normally SHARED flag won't change just due to a normal sync
operation.
But btrfs doesn't handle SHARED flag well, and this time it won't
check any delayed extent tree(reverse extent searching tree)
modification, but only metadata already committed to disk.
So btrfs will not return correct SHARED flag on reflinked files if
there is no sync to commit all metadata.
This testcase will just check it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
After GETNEXTQUOTA ioctl being supported, xfs_quota -c "report"
always outputs one more quota line about default quota (as project
ID 0). In order to fix this problem, xfsprogs has merged commit
3d607a1.
Now xfstests face this same problem from this issue. xfs/133 and
xfs/134 can't match their golden output, due to this one more line
quota report output. So this patch filters this redundant quota info
out.
There're 3 kinds of xfsprogs:
1. not support GETNEXTQUOTA
2. support GETNEXTQUOTA but not merged commit 3d607a1
3. the latest version supports all
The 1st one won't report Project ID 0, the 2nd will report projid 0
info as "(null) 0 0 0 ...", the 3rd will report projid 0 info as
"#0 0 0 0 ...". To deal with all of these situations, we will use
_filter_quota | grep -v "^#0 \|^(null) "
But if someone specifies a name for projid 0, e.g.
# cat $projid_file
# root:0
I think that means someone wants to deal with it by himself, the
common filter won't filter it out.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Darrick J. Wong
Tahsin Erdogan
Theodore Ts'o
Christoph Hellwig
Wang Xiaoguang
Brian Foster
Xiong Zhou
Eryu Guan
Eric Sandeen
Zorro Lang
Jeffrey Bastian
Jan Kara
Qu Wenruo