Run btrfs replace operations and remount with different compress
algorithms simultaneously with fsstress running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs replace operations and defrag simultaneously with fsstress
running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs replace operations and scrub simultaneously with fsstress
running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs subvolume create/mount/umount/delete and remount with
different compress algorithms simultaneously, with fsstress running in
background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs subvolume create/mount/umount/delete and btrfs defrag
operations simultaneously, with fsstress running in backgound.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs subvolume create/mount/umount/delete and btrfs scrub
operation simultaneously, with fsstress running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs subvolume create/mount/umount/delete and device replace
operation simultaneously, with fsstress running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs balance and replace operations simultaneously with fsstress
running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs balance and remount with different compress algorithms
simultaneously, with fsstress running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs balance and defrag operations simultaneously with fsstress
running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs balance and scrub operations simultaneously with fsstress
running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run btrfs balance and subvolume create/mount/umount/delete simultaneously,
with fsstress running in background.
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs where removing the flag FS_COMPR_FL
(chattr -c) from an inode wouldn't clear its compression property.
This was fixed in the following linux kernel patch:
Btrfs: add missing compression property remove in btrfs_ioctl_setflags
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs issue where we create a RO snapshot
to use for a send operation, which fails with a -ESTALE error,
due to the presence of orphan inodes accessible through the
snapshot's commit root but no longer present through the main
root.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: update commit root on snapshot creation after orphan cleanup
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs ioctl clone operation + fsync + log
recovery. The issue was that doing an fsync after cloning into
a file didn't gave any persistence guarantees as it should.
What happened was that the in memory metadata (extent maps)
weren't updated, which made the fsync code not able to detect
that file data has been changed and must be persisted to the
log.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: make fsync work after cloning into a file
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for the btrfs ioctl clone operation when the source range
contains hole(s) and the FS has the NO_HOLES feature enabled (file holes
don't need file extent items in the btree to represent them).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: fix clone to deal with holes when NO_HOLES feature is enabled
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for a btrfs incremental send issue where the difference
between the snapshots used by the incremental send consists of one of
these cases:
1) First snapshot has a directory with name X and in the second snapshot
that directory doesn't exist anymore but a subvolume/snapshot with
the same name (X) exists;
2) First snapshot has a subvolume/snapshot with name X and in the second
snapshot that subvolume/snapshot doesn't exist anymore (might have been
replaced by a directory with the same name or not).
This issue is fixed by the following linux kernel btrfs patches:
Btrfs: send, don't error in the presence of subvols/snapshots
Btrfs: set dead flag on the right root when destroying snapshot
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Verify that btrfs send is able to replicate xattrs larger than
PATH_MAX. This is possible if the b+tree leaf size is larger
than 4Kb (mkfs.btrfs's default is max(16Kb, PAGE_SIZE) as of
btrfs-progs v3.12, and max(4Kb, PAGE_SIZE in older versions).
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, use the right limits for xattr names and values
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is a test to verify that the btrfs ioctl clone operation is
able to clone extents of a file to different positions of the file,
that is, the source and target files are the same. Existing tests
only cover the case where the source and target files are different.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression test for btrfs send where long paths (exceeding 230 characters)
made send produce paths with random characters from a memory buffer returned
by kmalloc, as send forgot to populate the new buffer with the path string.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, fix corrupted path strings for long paths
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Regression for btrfs send when an inode only has extended references
associated to it (no regular references present). This used to cause
incorrect access to a b+tree leaf, where an extended reference item
was accessed as if it were a regular reference item, causing unexpected
and unpredictable behaviour such as producing a random/weird path string
or a crash.
This issue is fixed by the following linux kernel btrfs patch:
Btrfs: send, fix incorrect ref access when using extrefs
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This patch adds a regression test to verify btrfs can not
reuse inode id until we have committed transaction. Which was
addressed by the following kernel patch:
Btrfs: fix inode cache vs tree log
Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test case verifies the btrfs properties feature, a new feature
introduced in the linux kernel version 3.14.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test verifies that after an incremental btrfs send the
replicated file has the same exact hole and data structure as in
the origin filesystem. This didn't use to be the case before the
send stream version 2 - holes were sent as write operations of 0
valued bytes instead of punching holes with the fallocate system
call, and pre-allocated extents were sent as well as write
operations of 0 valued bytes instead of intructions for the
receiver to use the fallocate system call.
It also checks that prealloc extents that lie beyond the file's
size are replicated by an incremental send.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Eryu Guan
Filipe Manana
Wang Shilong
Filipe David Borba Manana