Check if SGID is cleared upon chmod / setfacl when the owner is not
in the owning group. As of today, the kernel fails to clear SGID in
setxattr (which is what acl_set_file is implemented on top of) in
that case; see this patch:
https://patchwork.kernel.org/patch/9290507/
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test sharing blocks via reflink and dedupe between two different
mountpoints of the same filesystem. This shouldn't work, since we
don't allow cross-mountpoint functions.
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>
Ensure that we can create a file with a single extent, reflink two
blocks out of the middle of that extent, and the resulting fiemap
reports two shared extents, instead of lazily reporting the entire
huge extent as shared.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Currently in btrfs, there is something wrong with fallocate(2)'s
data space reservation, it'll temporarily occupy more data space
thant it really needs, which in turn will impact other operations'
data request.
In this test case, it runs write(2) and fallocate(2) in parallel and
the total needed data space for these two operations don't exceed
whole fs free data space, to see whether we will get any unexpected
ENOSPC error.
Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test has been removed from the auto group because it fails without
an expected fix. Remove it from the quick group as well, as the quick
group should be a subset of the auto group.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS had a bug to hang on remount in this case, this kernel commit
fix the issue.
5cb13dc cancel the setfilesize transation when io error happen
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test symlink to very long path, so that path could not be hold in
inode, then check symlink file contains correct path.
There was a bug in CRC XFS, that the path in remote symlink was not
correct, this issue is fixed by this kernel commit
2ac56d3 xfs: fix remote symlinks on V5/CRC filesystems
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Ensure that we can handle the case where the refcount stays the same
even though the actual sharers changes.
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>
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>
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>
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>
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>
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>
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>
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>
Test that if we create a hard link for a file F in some directory A,
then move some directory or file B from its parent directory C into
directory A, fsync file F, power fail and mount the filesystem, the
directory/file B is located only at directory A and both links for
file F exist.
This test is motivated by an issue found in btrfs which is fixed by the
following patch for the linux kernel:
Btrfs: fix for incorrect directory entries after fsync log replay
Tested against ext3/4, xfs, reiserfs and f2fs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that if we rename a file, create a new file that has the old name
of the other file and is a child of the same parent directory, fsync the
new inode, power fail and mount the filesystem, we do not lose the first
file and that file has the name it was renamed to.
This test is motivated by an issue found in btrfs which is fixed by the
following patch for the linux kernel:
"Btrfs: fix file loss caused by fsync after rename and new inode"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Andreas Gruenbacher
Darrick J. Wong
Wang Xiaoguang
Christoph Hellwig
Eryu Guan
Jan Kara
Qu Wenruo
Dave Chinner
Filipe Manana
Eric Sandeen