Check that we can feed bad inputs to reflink/dedupe and it'll reject
them.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that the free block counts seem to be handled correctly in
the reflink operation and subsequent attempts to rewrite reflinked
copies.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check that the variants of fallocate (allocate, punch, zero range,
collapse range, insert range) do the right thing when they're run
against a range of reflinked blocks.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Ensure that CoW happens correctly with buffered, directio, and mmap writes.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test the operation of the btrfs (and now xfs) reflink and dedupe
ioctls at various file offsets and with matching and nonmatching
files.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Put all the reflink/dedupe-related test support routines in a separate
file, then modify the existing reflink tests to use them.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Move the cp --reflink tests from btrfs/ to generic/ since xfs now
supports that ioctl.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs now has changed to delete subvolume/snapshot asynchronously,
which means that after umount, if we've already deleted 'ext2_saved',
rollback can still be completed, which should not.
So this adds a regression test for this.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The ext4/301, ext4/302, ext4/303, and ext4/304 tests are not crashing
on 3.10.89, 3.14.53, 3.18.21, 4.1.8, and 4.3-rc2. So promote these
tests from the dangerous to the auto group.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that truncating a file that consists of a compressed and inlined extent
to a smaller size and then cloning it into another file is not possible and
does not result in leaking stale data (data past the truncation offset) nor
losing data in the clone operation's destination file.
This btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: fix truncation of compressed and inlined extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I forgot to add the requirement for the xfs_io command "falloc", which
the test makes use of. Also fixed a weird indentation (mix of spaces
and tabs) for one line of a comment.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The test currently verifies that cloning one file with an inline extent
with a size of 10 bytes into a file with an inline extent that has a size
of 20 bytes succeeds. But this results in data loss, because the btrfs
clone operation drops the 20 bytes inline extent from the destination
inode and then copies the 10 bytes inline extent from the source file
into the destination file, resulting in data loss of the last 10 bytes
of data that the destination file had.
Fixing btrfs to correctly operate for this case (not resulting in data
loss) is actually a lot of work and brings a lot of complexity, specially
considering that any of the inline extents can be compressed. For the
moment there's a fix to make the clone operation return the errno
EOPNOTSUPP and not touch any of the inodes. This is the same approach
we do for other cases involving operation against inline extents, so
this just adds one more case that should have never been allowed.
Cloning inline extents is a rare operation and pointless, since it
involves copying them and not doing any actual deduplication or saving
space.
The btrfs patch for the linux kernel that prevents this data loss,
and fixes some file corruption cases, is titled:
"Btrfs: fix file corruption and data loss after cloning inline extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test several cases of cloning inline extents that used to lead to file
corruption or data loss.
These file corruption and data loss cases are fixed by the linux kernel
patch titled:
"Btrfs: fix file corruption and data loss after cloning inline extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The runas helper runs a command as another user and/or with different group
memberships. Fix the following problems:
* Use setgid instead of setegid and setuid instead of seteuid.
Otherwise, the command will run with the original real UID
and/or GID; those could be made the effective IDs again.
* When only a GID is specified, remove all supplementary
GIDs. Otherwise, the command would remain in the same
supplementary groups as runas -- which often is the root
group.
* Use execvp instead of execv which searches the PATH when
necessary. The runas helper is always called either with a
'/' in the pathname or as "runas ... `which program`", so
we obviously want PATH lookup, anyway.
* There is no advantage in fork'ing and waiting for the child
over directly exec'ing the command; the test cases already
have to deal with commands which can be killed by signals.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that sending a snapshot received from a different filesystem is
possible for both full and incremental send operations.
This used to work until the linux kernel release 4.2, but a commit [1] in
that release introduced a regression which did not allow this anymore.
The regression is fixed by the linux kernel patch titled:
"btrfs: fix resending received snapshot with parent"
[1] 37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")
Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that sending and receiving snapshots across different filesystems
works for full and incremental send operations.
This used to fail before the linux kernel release 4.2. The linux kernel
commit that fixed this issue was the following:
37b8d27de5d0 ("Btrfs: use received_uuid of parent during send")
Cc: Josef Bacik <jbacik@fb.com>
Cc: Robin Ruede <rruede+git@gmail.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
sync doesn't guarantee all fsstress processes died, and sometimes it
ends up running fsck on a mounted fs.
Use wait to wait for fsstress to exit.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to) that have compressed extents.
This used to fail on btrfs, resulting in different file digests after
receiving the send stream, and got fixed by the linux kernel patch
titled:
"Btrfs: send, fix file corruption due to incorrect cloning operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that a send operation works correctly with reflinked files (cloned
extents which multiple files point to).
The btrfs issue was fixed by the linux kernel patch titled:
"Btrfs: send, fix file corruption due to incorrect cloning operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Even the fallocate range doesn't cover the last page of a file, btrfs
will still re-truncate the last page.
Such behavior is completely duplicated and unneeded, and fixed by the
following kernel patch:
btrfs: Avoid truncate tailing page if fallocate range doesn't exceed
inode size
Add this test case to check that malfunction.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This tests Brian Foster's fix for xfs:
xfs: always drain dio before extending aio write submission
It launches four adjacent 1k IOs past EOF, then reads back
to see if we have 4k worth of the data we wrote, or something else -
possibly zeros from sub-block zeroing and eof racing.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
generic/085 was failing on a machine w/o devicemapper kernel
support because it requires the linear target, but didn't
explicitly test for it.
I could have cut & pasted _require_dm_linear(), but chose
to go the route of a generic helper, _require_dm_target $FOO,
because some day someone will need the zero target, the error
target, or who knows.
Add the helper, use it in test generic/085, and convert
_require_dm_flakey, _require_dm_snapshot, and
_dmerror_required with this new helper.
Reported-by: Angelo Dureghello <angelo.dureghello@nomovok.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for file read corruption when using compressed extents
that represent file ranges with a length that is a multiple of 16 pages
and that are shared by multiple consecutive ranges of the same file.
This is similar to the test added in commit 694db0c050 ("btrfs: read
corruption of compressed extents"), but tests the special case where the
extent's uncompressed length is a multiple of 16 pages. The first btrfs
fix, tested by the test added in the commit mentioned before, failed to
address this special case.
This btrfs issue is fixed by the linux kernel patch titled:
"Btrfs: update fix for read corruption of compressed and shared extents"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Darrick J. Wong
Xiong Zhou
Liu Bo
Theodore Ts'o
Filipe Manana
Andreas Gruenbacher
Eryu Guan
Qu Wenruo
Eric Sandeen
Eric Sandeen