The test does the following:
Initialize a RAID5 with some data
Re-mount RAID5 degraded with _dev3_ missing and write data.
Save md5sum checkpoint1
Re-mount healthy RAID5
Let balance fix degraded blocks.
Save md5sum checkpoint2
Re-mount RAID1 degraded now with _dev1_ missing.
Save md5sum checkpoint3
Verify if all three md5sum matches
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test does the following:
Initialize a RAID1 with some data
Re-mount RAID1 degraded with _dev1_ and write up to
half of the FS capacity
Save md5sum checkpoint1
Re-mount healthy RAID1
Let balance re-silver.
Save md5sum checkpoint2
Re-mount RAID1 degraded with _dev2_
Save md5sum checkpoint3
Verify if all three md5sum match
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Btrfs after v4.2 kernel will leaks qgroup numbers for relocated data
extents, due to the design of tree block direct swap.
This test case will check if such data balance will corrupt qgroup.
Reported-by: Mark Fasheh <mfasheh@suse.de>
Reported-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test if qgroup can handle extent de-reference during reallocation.
"extent de-reference" means that reducing an extent's reference
count or freeing an extent.
Although current qgroup can handle it, we still need to prevent any
regression which may break current qgroup.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.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>
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>
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>
Test that if we delete a snapshot, delete its parent directory, create
another directory with the same name as that parent and then fsync either
the new directory or a file inside the new directory, the fsync succeeds,
the fsync log is replayable and produces a correct result.
This is motivated by a bug that is fixed by the following patch for
btrfs (linux kernel):
Btrfs: fix unreplayable log after snapshot deletion and parent
re-creation
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 replaying a log tree when qgroups are enabled and orphan roots
(deleted snapshots) exist, the replay process does not crash.
This is motivated by a bug found in btrfs, introduced in the linux kernel
4.4 release, and is fixed by the linux kernel commit 909c3a22da3b
("Btrfs: fix loading of orphan roots leading to BUG_ON") that landed in
kernel 4.5.
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 fsync a directory that had a snapshot entry in it that
was deleted and crash, the next time we mount the filesystem, the log
replay procedure will not fail and the snapshot is not present anymore.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: fix unreplayable log after snapshot delete + parent dir fsync"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Tested-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that an incremental send operation which issues clone operations
works for files that have a full path containing more than one parent
directory component.
This used to fail before the following patch for the linux kernel:
"[PATCH] Btrfs: send, fix extent buffer tree lock assertion failure"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Verify that when a fitrim operation is made against a btrfs filesystem,
the ranges [0, 64Kb[ and [68Kb, 1Mb[ of the device are not discarded,
they remain with the content they had before the fitrim operation. These
regions of the device are reserved for a boot loader to use at its will.
In the 4.3 linux kernel we got a regression that allowed a fitrim
operation to discard these reserved ranges of the device, resulting in
the filesystem becoming unbootable after a fitrim. The issue is fixed
by the following patch (targeted for 4.5 and 4.3/4.4 stable releases):
"Btrfs: fix fitrim discarding device area reserved for boot loader's use"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that doing a direct IO write against a file range that contains one
prealloc extent and one compressed extent works correctly.
From the linux kernel 4.0 onwards, this either triggered an assertion
failure (leading to a BUG_ON) when CONFIG_BTRFS_ASSERT=y or resulted
in an arithmetic underflow of an inode's space reservation for write
operations.
That issue is fixed by the following linux kernel patch:
"Btrfs: fix extent accounting for partial direct IO writes"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case tests if we are able to disable quotas on a filesystem
while a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: fix quota disable during rescan).
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case tests if we are able to unmount a filesystem while
a quota rescan is running. Up to now (4.3) this would result
in a kernel NULL pointer dereference.
Fixed by patch (btrfs: qgroup: exit the rescan worker during umount).
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
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>
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>
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>
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>
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>
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>
Test that an incremental send works after a file from the parent snapshot
gets replaced in the send snapshot by another one at the same exact
location, with the same name and with the same inode number.
This test used to fail after the linux kernel commit 8b191a684968
("Btrfs: incremental send, check if orphanized dir inode needs delayed
rename") and it's fixed by patch titled:
"Btrfs: send, fix corner case for reference overwrite detection"
Signed-off-by: Martin Raiber <martin@urbackup.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Anand Jain
Qu Wenruo
Lu Fengqi
Omar Sandoval
Mark Fasheh
Filipe Manana
Justin Maggard
Darrick J. Wong