Run several duperemove processes with fsstress on same directory at
same time. Make sure the race won't break the fs or kernel.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This case does dedupe on a dir, then copy the dir to next dir.
Dedupe the next dir again, then copy this dir to next again, and
dedupe again ... At the end, verify the data in the last dir is
still same with the first one.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Duperemove is a tool for finding duplicated extents and submitting
them for deduplication, and it supports XFS. This case trys to
verify the integrity of XFS after running duperemove.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Recently we found out xfs_repair were not repairing root inode
parent pointer when root inode is on short-form and parent points to
an invalid inode number (refer to: "xfs_repair: Fix root inode's
parent when it's bogus for sf directory" on xfs-devel list).
This test checks if xfs_repair successfully repair the filesystem in
the scenario mentioned before.
Signed-off-by: Marco Benatto <mbenatto@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In "xfs: fix fdblocks accounting w/ RMAPBT per-AG reservation", we fixed
the per-ag reservation code so that we always decrease fdblocks by the
reserved size because rmapbt blocks are counted as free space.
The primary symptom of this bug is that if the rmapbt has expanded since
mount time, the disk block counters reported via statfs will change
across a remount. Therefore, we exercise this as a regression test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
I apparently never bothered to put copyright or license info with this
code, just tag it as GPL 2 and I'll fix the upstream stuff as well.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
In kernel patch "xfs: verify root inode more thoroughly", we strengthen
the root inode mount checks to make sure that the inobt agrees that the
root inode exists and is in use. Unfortunately, that makes this whole
test useless because we can't even mount the filesystem to run scrub.
So, redirect it to AG1's inobt.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Mostly scripted like all the others, manually added tags to
Makefile. aio-stress.c was manually touched up before scripted
conversions.
Notes for future reference:
- fsx.c license is ambiguous. Not tagged in any way.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Mostly scripted like all the others, manually added tags to
Makefile, nsexec.c and t_mmap_writev.c. Manually touched up
open_by_handle.c and t_encrypted_d_revalidate.c post script.
Notes for future reference:
- src/log-writes/ code has no explicit copyright or license tags,
nor does the upstream repository, hence license is unknown.
Need Josef to clarify the license and send a patch adding SPDX
tags to those files.
- src/perf code has no explicit copyright or license tags, but it
was code submitted explictly for fstests so it is assumed to be
GPLv2.0 and tagged as such. If this is incorrect, Josef will need
to clarify copyright and the license and send patches to correct
it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
The license headers all had to be manually editted into a consistent
format, then converted to spdx tags via scripting. Manually added
tag to Makefile.
Notes for future reference and research:
- quoted source repositories for aio-dio suite no longer exist
- src/aio-dio-regress/aiodio_sparse2.c has no explicit license
statement, so need to find original source to determine actual
license before tagging.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
I noticed that in some of my C tests in src/ I was incorrectly
checking for mmap() failure by looking for NULL instead of
MAP_FAILED. Fix those and clean up some places where we were
testing against -1 (the actual value of MAP_FAILED) which was
manually being cast to a pointer.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Move get_sfdir_prefix function from xfs/278 to commom/xfs
and rename it to _scratch_get_sfdir_prefix so it can be
used in other xfs tests.
This commit also changes xfs/278 to make use of
_scratch_get_sfdir_prefix instead previous one.
Signed-off-by: Marco Benatto <mbenatto@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since btrfs-dump-tree has been removed from btrfs-progs, use btrfs
inspect-internal dump-tree instead of btrfs-dump-tree.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The FIEMAP_EXTENT_SHARED flag was added into kernel since commit
8c0414cd524e, so undefined FIEMAP_EXTENT_SHARED resulted in complier
error on old distros(e.g. RHEL6), as below:
----------------------------------------------------------------------
t_stripealign.c:99: error: 'FIEMAP_EXTENT_SHARED' undeclared (first use in this function)
----------------------------------------------------------------------
We fix it by defining the flag manually.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfs/170 always fails on xfs with "-m rmapbt=1,reflink=1", because
XFS need bigger internal log size if rmapbt and reflink are both
enabled.
One line of xfs/170 as below:
_test_streams 8 16 4 8 3 0 0
Refer to common/filestreams, we can see xfs/170 trys to create a
128M XFS (agcount=8, agsize=16M), then each stream writes
24M (8 * 3M files), and there're 4 streams.
So the case expects each stream takes 2 AGs, 4 streams takes
different 8 AGs just enough. But internal log will break this
balance. For example:
"mkfs.xfs -f -b size=4k -m rmapbt=1,reflink=1 $dev" will take 3075
4k blocks (12M) by default:
meta-data=/dev/mapper/xxxx-xfscratch isize=512 agcount=8, agsize=4096 blks
...
log =internal bsize=4096 blocks=3075, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
...
And the internal log is in the 4th AG:
# xfs_logprint: /dev/mapper/xxxx-xfscratch
xfs_logprint:
data device: 0xfd03
log device: 0xfd03 daddr: 131120 length: 24600
# xfs_db -c "convert daddr 131120 agno" /dev/mapper/xxxx-xfscratch
0x4 (4)
Then if one stream write data into AG-1 at first, then turn to AG-4
after fill 16M agsize. But AG-4 has 12M space for log section, so
only 4M free space for data. Then this stream have to turn to the
next AG after fill the 4M space. All these as below:
# xfs_bmap -vp stream2-dir/*
stream2-dir/frame-1:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..6143]: 32960..39103 1 (192..6335) 6144 000000
...
...
stream2-dir/frame-5:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..6143]: 57536..63679 1 (24768..30911) 6144 000000
stream2-dir/frame-6:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..6143]: 155776..161919 4 (24704..30847) 6144 000000
stream2-dir/frame-7:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..6143]: 170088..176231 5 (6248..12391) 6144 000000
stream2-dir/frame-8:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS
0: [0..6143]: 176232..182375 5 (12392..18535) 6144 000000
Later _test_streams maybe takes AG-5 again, and cause two streams use
AG-5. To avoid this failure, increase the agsize from 16M to 22M,
others stay the same, each stream still writes 2 AGs. Even internal
log takes some space from someone AG, left space should be enough to
write (24 - 22)=2M data.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Since XFS has deprecated FIBMAP on FSDAX filesystems, we can't use
FIBMAP to verify stripe alignment anymore. FIEMAP has existed for
quite some time now, so port it to use that instead, and only fall
back to FIBMAP if FIEMAP doesn't exist.
Tested-by: ross.zwisler@linux.intel.com
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add btrfs test that checks "rmdir" or "rm -r" command can delete a
subvolume like an ordinary directory.
This behavior has been restricted long time but becomes allowed by
kernel commit a79a464d5675 ("btrfs: Allow rmdir(2) to delete an
empty subvolume")
The test will be skipped if kernel does not support the feature,
which can be checked whether /sys/fs/btrfs/features/rmdir_subvol
exists or not.
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When running multiple fsx processes simultaneously (e.g.
generic/455), it is difficult to tell the seed value for one fsx
process if the seed value is needed to reproduce a log-replay
failure.
Fix it by outputting the seed value after logid is initialized.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we create a new hard link for a file which was
previously fsync'ed, fsync a parent directory of the new hard link
and power fail, the parent directory exists after mounting the
filesystem again. The parent directory must be a new directory, not
yet persisted.
This test is motivated by a bug found in btrfs, where the fsync'ed
parent directory was lost after a power failure. The bug in btrfs is
fixed by a patch for the linux kernel titled:
"Btrfs: sync log after logging new name"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On filesystems that do not support O_DIRECT, the test should skip
itself with
generic/391 [not run] O_DIRECT is not supported
instead of failing with
generic/391 - output mismatch ...
...
+open: Invalid argument
Silence is golden
...
This patch make it do that by adding a call to _require_odirect.
Fixes https://github.com/rfjakob/gocryptfs/issues/244 .
Signed-off-by: Jakob Unterwurzacher <jakobunt@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
A dmesg output as below cause all cases fail:
[ 508.002072] EDAC DEBUG: ie31200_check: MC0
Due to it matches `egrep -e "BUG:"` in _check_dmesg. But it's not a
real BUG output, so use "\bBUG:" to avoid this mistake.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The regex matches used to dump the test headers are no longer valid,
so update them to work with the new test header format.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Zorro Lang
Marco Benatto
Darrick J. Wong
Josef Bacik
Dave Chinner
Ross Zwisler
Lu Fengqi
Xiao Yang
Misono Tomohiro
Hou Tao
Filipe Manana
Jakob Unterwurzacher