Make sure missing device is included in the alloc list when it is
scanned on a mounted FS.
This test case needs btrfs kernel patch which is in the ML
[PATCH] btrfs: handle dynamically reappearing missing device
Without the kernel patch, the test will run, but reports as
failed, as the device scanned won't appear in the alloc_list.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test case writes into pre-allocated space, then tries to
fallocate some more within the defined quota limit. Currently
(4.14-rc7) this fails with EDQUOT due to quota reservation leakage
when writing into pre- allocated space.
A possible fix has been sent to the ML as "btrfs: Fix quota
reservation leak on preallocated files"
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test case does some concurrent send/receives with qgroups
enabled. Currently (4.14-rc7) this usually results in btrfs check
errors, and often also results in a WARN_ON in
record_root_in_trans().
Bisecting points to 6426c7ad697d (btrfs: qgroup: Fix qgroup
accounting when creating snapshot) as the culprit.
Signed-off-by: Justin Maggard <jmaggard@netgear.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
No agreement on how to fix it in the foreseeable future. So remove
it from auto group to prevent newbie tester from spending days
waiting it to finish.
Reported-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Currently running 'btrfs device delete' can end up with losing data
raid profile (if any), this test is to reproduce the problem.
The fix is
"Btrfs: avoid losing data raid profile when deleting a device"
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
We had a bug in btrfs compression code which could end up with a
kernel panic.
This is adding a regression test for the bug and I've also sent a
kernel patch to fix the bug.
The patch is "Btrfs: fix kernel oops while reading compressed data".
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send/receive operation will not fail when the
destination filesystem has compression enabled and the source filesystem
has a 4K extent at a file offset 0 that is not compressed and that is
shared.
This currently fails on btrfs and is fixed by the following patch for the
linux kernel:
"Btrfs: incremental send, fix emission of invalid clone 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 a direct IO write works against raid5/6 filesystems and that
after the write operation we are able to read back the correct data
and scrub operations don't find any errors.
This test is motivated by a regression introduced in the merge window
for the 4.13 linux kernel, which was undetected by the current set of
test cases. The issue is fixed by the following patch:
"Btrfs: fix write corruption due to bio cloning on raid5/6"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send/receive operation works correctly after
moving some directory inode A, renaming a regular file inode B into the
old name of inode A and finally creating a new hard link for inode B at
directory inode A.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix invalid path for link commands"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
For btrfs, we can test how it reports data writeback errors on fsync by
implementing a suggestion from Chris Mason:
Build a filesystem with 2 devices that stripes the data across
both devices, but mirrors metadata across both. Then, make one
of the devices fail and test what it does.
[eguan: add comments about creating btrfs with "-d raid0 -m raid1"]
Cc: Chris Mason <clm@fb.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
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>
Anand Jain
Justin Maggard
Qu Wenruo
Liu Bo
Filipe Manana
Jeff Layton
Omar Sandoval
Goldwyn Rodrigues
Lakshmipathi.G