Test that an incremental send works if we rename some directory inode A
and then rename some file inode B to the name inode A had, for the case
where the directory inode A is an ancestor of inode B in the parent
snapshot.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix invalid path for unlink commands"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works correctly when an inode A
is renamed, a new hard link added to it and some other inode B is renamed
to the old name of inode A.
The btrfs bug is fixed by the following patch for the linux kernel:
"Btrfs: send, fix invalid path after renaming and linking file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is a regression test for patch "Btrfs: fix delalloc accounting
leak caused by u32 overflow". It creates a bunch of delalloc extents
and merges them together to make sure the accounting is done right.
[eguan: use $XFS_IO_PROG instead of xfs_io]
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is to test whether buffered read retry-repair code is able to
work in raid1 case as expected.
Please note that without checksum, btrfs doesn't know if the data
used to repair is correct, so repair is more of resync which makes
sure that both of the copy has the same content.
Commit 20a7db8ab3f2 ("btrfs: add dummy callback for
readpage_io_failed and drop checks") introduced the regression.
The upstream fix is commit 9d0d1c8b1c9d ("Btrfs: bring back repair
during read")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized
blocks") introduced this regression. It'd cause 'Segmentation
fault' error.
The upstream fix is commit 97bf5a5589aa ("Btrfs: fix segment fault
when doing dio read")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case tests whether buffered read can repair the bad copy if we
have a good copy.
Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed
and drop checks") introduced the regression.
The upstream fix is commit 9d0d1c8b1c9d ("Btrfs: bring back repair
during read")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case tests whether dio read can repair the bad copy if we have
a good copy.
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized
blocks") introduced the regression.
The upstream fix is commit 2e949b0a5592 ("Btrfs: fix invalid
dereference in btrfs_retry_endio")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Since snapshot aware defrag has been disabled in kernel, and we all
have learned to ignore the failure of btrfs/010, lets just remove
it.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If we create and delete files within the qgroup limits, qg->reserved
(allocations before commits) over-inflates and causes -EDQUOT to be
returned pre-maturely.
Also, 32/64bit data-type exchanges can cause reserved (u64) to go
negative (very large) and -EDQUOT is returned pre-maturely.
Will be fixed by patches with subjects:
btrfs: Retry after commit on getting EDQUOT
btrfs: Change qgroup_meta_rsv to 64bit
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is a regression test for "Btrfs: fix btrfs_decompress_buf2page()".
It fails for zlib on v4.10-rc[1-7].
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that both a full and incremental btrfs send operation preserves
file holes.
This used to fail when the filesystem had the NO_HOLES feature enabled,
that is, when the test is run with MKFS_OPTIONS="-O no-holes".
This is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix unnecessary hole writes for sparse files"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is used to check the source which contains combination of Ext3
files in non-extent format and Ext4 extent-files. And validate the
file md5sums before and after conversion.
btrfs/012: BTRFS_CONVERT_PROG,E2FSCK_PROG definitions reused from
common/config
Signed-off-by: Lakshmipathi.G <Lakshmipathi.G@giis.co.in>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is a regression test for "Btrfs: disable xattr operations on
subvolume directories". On v4.9, it will result in an aborted
transaction.
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works when in both snapshots
there are two directory inodes that have the same number but
different generations and have an entry with the same name that
corresponds to different inodes in each snapshot.
The btrfs issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, do not issue invalid rmdir operations"
Signed-off-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works after moving a
directory into a new parent directory, deleting its previous parent
directory and creating a new inode that has the same inode number as
the old parent.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, do not delay rename when parent inode is new"
Signed-off-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation does not fail when a new
inode replaces an old inode that has the same number but different
generation, and both are direct children of the subvolume/snapshot
root.
This is fixed by the following patch for the linux kernel:
"Btrfs: send, fix failure to rename top level inode due to name
collision"
Signed-off-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Btrfs upstream doesn't accept stream-version, so the test is never
ran on upstream kernel nor btrfs-progs.
Just remove it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Due to the fact that btrfs uses different max extent size for
compressed and non-compressed write, it calculates metadata
reservation incorrectly.
This can leads to false ENOSPC alert for compressed write.
This test case will check it by using small fs and do parallel write
to trigger it.
It's highly recommened to use MOUNT_OPTIONS="-o compress" and
MKFS_OPTIONS="-n 64k" to trigger it. Without compression, it won't
be triggered.
The fix is not merged and may change in the future, but the function
is good enough:
btrfs: improve inode's outstanding_extents computation
btrfs: fix false enospc for compression
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The behavior of different combinations of space_cache mount options
wasn't well defined, which led to a regression between my initial
patches adding the free space tree and the 4.5 release. Add a test to
exercise all of the meaningful permutations of clear_cache,
nospace_cache, and space_cache.
This is a regression test for Linux kernel commit "Btrfs: fix mount -o
clear_cache,space_cache=v2".
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Define test groups for those tests which have _require_xfs_io_command
for punch, collapse, insert, and zero. This makes it easier to
exclude tests that use one of these fallocate commands. Or if you
want to specifically test for those fallocate commands you can do
this.
This obviates an out-of-tree xfstests patch I maintain which used an
XFS_IO_AVOID environment variable to suppress running tests that use
punch, collapse, insert, etc. This was rejected because of the
claim that it could be done using groups. So this commit is in
response to those upstream comments.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Update the following quick/auto tag based on their execution time
btrfs/007
btrfs/050
btrfs/100
btrfs/101
Two systems are used to determine their execution time. One is
backed by an SATA spinning rust, whose maximum R/W speed is about
100MB/s, modern desktop performance. (VM1)
Another one is a VM inside a openstack pool, with stronger CPU and
memory performance along with high latency storage. Maximum R/W
speed is around 150MB/s, latency is much higher than normal HDD
though. (VM2)
The 'quick' standard is a little more restrict, only when both
systems pass the test within 30s(+/- 10%), while 'auto' is less
restrict, any system can pass within 5min(+/- 10%) will still stay
in 'auto' group.
Other test cases don't fit both standards on both systems will not
be modified.
Execution time result: (Unit: seconds)
------------------------------------------------------
Test case No. | VM1 | VM2 | Modification |
------------------------------------------------------
btrfs/007 | 4 | 2 | +quick |
btrfs/050 | 4 | 13 | +quick |
btrfs/100 | 57 | 151 | -quick |
btrfs/101 | 45 | 59 | -quick |
------------------------------------------------------
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
For fully deduped file, whose file extents are all pointing to the
same extent, btrfs backref walk can be very time consuming, long
enough to trigger softlock.
Unfortunately, btrfs send is one of the caller of such backref walk
under an O(n) loop, making the total time complexity to O(n^3) or
more.
And even worse, btrfs send will allocate memory in such loop, to
trigger OOM on system with small memory(<4G).
This test case will check if btrfs send will cause these problems.
Reporeted-by: Tsutomu Itoh <t-itoh@jp.fujitsu.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 that an incremental send operation does not prematurely issues
rmdir operations under a particular scenario (the rmdir operation is
sent before the target directory is empty).
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix premature rmdir operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that, under a particular scenario, an incremental send
operation does not leak memory (which used to emit a warning in
dmesg/syslog).
This is a regression test for a btrfs kernel fix that has the title:
"Btrfs: send, fix warning due to late freeing of orphan_dir_info
structures".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works after doing radical
changes in the directory hierarchy that involve switching the inode
that directory entries point to.
This test exercises scenarios used to fail in btrfs and are fixed by
the following patches for the linux kernel:
"Btrfs: send, fix failure to move directories with the same name around"
"Btrfs: incremental send, fix invalid paths for rename operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Filipe Manana
Omar Sandoval
Liu Bo
Goldwyn Rodrigues
Lakshmipathi.G
Qu Wenruo
Theodore Ts'o