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>
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>
Some tests were merged with high, non-conflicting test numbers
(700+). Renumber them down to contiguous numbers now that all the
other tests have been added, as it's easier to do it this way rather
than having to rebase and have to fix all the conflicts early
renumbering will cause.
Signed-off-by: Dave Chinner <david@fromorbit.com>
There're many tests don't remove $seqres.full before writing to it, and
accumulating logs there, then the logs are always growing over time.
Let's fix them once.
generic/16[1-8] generic/170 and generic/33[34] truncate $seqres.full in
the middle of the test, which results in partial logs. Fix them as well.
xfs/227 has duplicated lines to remove $seqres.full, remove the extra
line.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Now that _btrfs_get_profile_configs supports replace missing and the
kernel doesn't crash when replacing a missing RAID 5/6 device, test it.
Based on an earlier test from Wang Yanfeng.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test creating a symlink, fsync its parent directory, power fail and mount
again the filesystem. After these steps the symlink should exist and its
content must match what we specified when we created it (must not be
empty or point to something else).
This is motivated by an issue in btrfs where after the log replay happens
we get empty symlinks, which not only does not make much sense from a
user's point of view, it's also not valid to have empty links in linux
(wgich is explicitly forbidden by the symlink(2) system call).
The issue in btrfs is fixed by the following patch for the linux kernel:
"Btrfs: fix empty symlink after creating symlink and fsync parent dir"
Tested against ext3, ext4, xfs, f2fs, reiserfs and nilfs2.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This has been broken since Linux v4.1. We may have worked out a solution on
the btrfs list but in the meantime sending a test to expose the issue seems
like a good idea.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Changing file attr in overlayfs triggers copy up.
Test this by changing mode bits then check both mode
bits and copy up results.
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Once a while, overlayfs whiteout can be visible if upper fs
does not support d_type(ftype/filetype). Test as a sanity
check on whiteout of regular files, links, dirs, devices
and pipes.
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Fairly trivial test to use the dm-thin infrastructure.
Right now it exhausts space in queue-on-error mode,
adds more space, does a bit more IO, then unmounts &
checks the fs.
Not sure if that's valid to test, but it works here and
demonstrates the common/dmthin helpers.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Although the test waits for running subshells after sending SIGTERM
signal to them, it does not wait for subprocesses of those subshells
properly. Thus we can hit EBUSY errors when umount is called. Make
subshells wait for executed subprocesses when receiving SIGTERM to avoid
the problem.
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test which spawns two processes both writing one file via mmap.
Then to the test when processes first prefault the file by reading it
via mmap. This is mainly interesting to uncover races in DAX fault
handling.
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test which spawns two threads both writing one file via mmap which
has been previously prefaulted by reading. Do the same test when one
thread accesses the file via mmap and the other one via normal write.
This is mainly interesting to uncover races in DAX fault handling and
between DAX fault handling and write path.
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test which spawns two threads one writing to file via normal write
and one via mmap and checks the result. This is mainly interesting to
uncover races between DAX fault handling and write path.
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Currently holetest program uses both posix_fallocate(3) and fallocate(3)
to setup the file. However this unnecessarily prolongs the test run and
doesn't really bring any additional code coverage. So remove the
fallocate(3) pass as using posix_fallocate(3) allows us to make the test
easily runnable even for filesystems not supporting that (such as ext2).
Signed-off-by: Jan Kara <jack@suse.cz>
Acked-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an invalid parent qgroup does not cause snapshot create to
force the FS readonly.
In btrfs, create_pending_snapshot() will go readonly on _any_ error return
from
btrfs_qgroup_inherit(). If qgroups are enabled, a user can crash their fs by
just making a snapshot and asking it to inherit from an invalid qgroup.
This patch does exactly that test. If the FS goes readonly that will be
reported and we will know that a regression was introduced.
The btrfs fix this patch relates to can be found at the following url:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/54755
Thanks,
--Mark
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
In xfs/299, project IDs are in $tmp.projid file. But there's one
line code try to use $temp.projid. Fortunately, it doesn't bring
any problems until now, but if keep using $temp.projid it really
don't make sense.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Currently xfs/259 tests against TEST_DIR for CRC support status to
decide whether 512 block size should be tested, which is wrong for this
test, because configuration of TEST_DIR is not controlled by test
harness and can be different to the configuration being used in the
test.
Fix it by reversing the block size order that's tested and capture the
output of the actual mkfs command that is being tested, and determine if
512 byte block sizes should be tested based on that output.
While we're at it, I think the test matrix can be enlarged as well, 4k,
2k, 1k and 512 block size can be tested in each fs size boundary, not
only the minimum block size.
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Now that we're wiring up fallocate's PUNCH_HOLE and ZERO_RANGE
features for block devices, add some tests to make sure they
work correctly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
If run btrfs/091 with "-o compress=lzo" mount option, test case will
fail, as compress makes extent much smaller on disk, making output
different from golden output.
As this test case is only testing qgroup, not compression, disable
compression manually in test case.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Eryu Guan
Eric Sandeen
Jan Kara
Qu Wenruo
Zorro Lang
Dave Chinner
Omar Sandoval
Filipe Manana
Mark Fasheh
Xiong Zhou
Eric Sandeen
Darrick J. Wong