The test is merged under index 202 but the golden output contains
201. This makes the test always fail. Correct the number.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that files from middle layer on same fs as upper layer
are not allowed to export the real inode st_dev;st_ino.
This is a regression test for kernel commit:
9c6d8f13e9da ("ovl: fix corner case of non-unique st_dev;st_ino")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Compilation failed on Fedora 20 because stdbool.h is not included in
xfs/platform_defs-x86_64.h or xfs/linux.h on Fedora 20.
Also, yang xiao fixed similar problem(commit 234f51ebbd) for fsx.c in
2016.2, but after that, fsstress.c started to use bool variable without
including stdbool.h file. It may fail on old linux distributions, so
fix it.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test removal of a subvolume via rmdir after it has been renamed into a
snapshot of the volume that originally contained the subvolume
reference.
This currently fails on btrfs but is fixed by the patch with the title
"btrfs: fix invalid removal of root ref"
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
On 32-bit systems, the offsets are 'unsigned long' (32-bit) which means
that we must cast the explicitly to unsigned long long before feeding
them to llabs. Without the type conversion we fail to sign-extend the
llabs parameter, try to make a copy/clone/dedupe call with overlapping
ranges, and fsx aborts and the test fails.
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>
IMHO, if kernel doesn't supprt realtime, we should skip test.
So add it. Also, when we use _scratch_mkfs on xfs, we will get
the following error:
mkfs failed with extra mkfs options added to "-bsize=4096" by test 590 **
This failure occurs because we have used "export XFS_MKFS_OPTIONS=
${XFS_MKFS_OPTIONS:=-bsize=4096}" in common/config, we don't need to
set it again in extra_options, so remove it.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The ability to use a mounted device node as the primary argument
to xfs_growfs was added back in with:
7e8275f8 xfs_growfs: allow mounted device node as argument
because it was an undocumented behavior that some userspace depended on.
This test exercises that functionality.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For historical reasons having to do with Solaris ACL behavior, the Linux
client treats an ACL like the one used as an example here as equivalent
to a mode, causing listxattr to report that no ACL is set on the file.
(See the comment at the top of fs/nfs_common/nfsacl.c in the kernel
source for details, and the "bogus ACL_MASK entry" comment in the same
source file.) This causes a spurious generic/529 failure on NFS.
As far as I can tell any ACL should trigger the original XFS problem.
So, modify it so as not to hit this odd NFS corner case.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In my testing on 1GB zram devices btrfs/139 usually fails with
ENOSPC.
Add a requirement for 2GB scratch devices (empirically measured).
Signed-off-by: Johannes Thumshirn <jth@kernel.org>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
With btrfs-progs v5.4, btrfs/140 and btrfs/141 will fail.
[CAUSE]
Both tests are testing re-silvering of RAID1, thus they need to corrupt
on-disk data.
This requires to do manual logical -> physical bytes mapping in the test
case.
However the test case itself uses too many hard coded helper to grab
physical offset, which will change with mkfs.btrfs.
[FIX]
Use more flex helper, to get both devid and physical for such
corruption.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When we're reloading the error-target dm table, always resume the device
even if the reload fails because (a) we shouldn't leave dm state for the
callers to clean up and (b) the caller don't clean up the state which
just leads to the scratch filesystem hanging on the suspended dm error
device.
Resume the dm device when we're cleaning up so that cleaning up the
scratch filesystem won't hang.
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>
Verify ciphertext for v2 encryption policies that use the IV_INO_LBLK_64
flag and use AES-256-XTS to encrypt file contents and AES-256-CTS-CBC to
encrypt file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Update _verify_ciphertext_for_encryption_policy() to support encryption
policies with the IV_INO_LBLK_64 flag set.
This flag modifies the encryption to include the inode number in the IVs
and to use a key derived from the tuple [master_key, fs_uuid, mode_num].
Since the file nonce is *not* included in this key derivation, multiple
files can use the same key.
This flag is supported by v2 encryption policies only -- not by v1.
Signed-off-by: Eric Biggers <ebiggers@google.com>
In preparation for adding 3 more input parameters to get_key_and_iv(),
create a structure to hold the input parameters so that the code doesn't
get too unwieldy.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
When using btrfs-progs v5.4, btrfs/157 and btrfs/158 will fail:
btrfs/157 1s ... - output mismatch (see xfstests/results//btrfs/157.out.bad)
--- tests/btrfs/157.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/157.out.bad
2019-12-10 15:35:43.112390076 +0000
@@ -1,9 +1,9 @@
QA output created by 157
wrote 131072/131072 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
+wrote 65536/65536 bytes at offset 22020096
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
...
(Run 'diff -u xfstests/tests/btrfs/157.out xfstests/results//btrfs/157.out.bad' to see the entire diff)
btrfs/158 2s ... - output mismatch (see xfstests/results//btrfs/158.out.bad)
--- tests/btrfs/158.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/158.out.bad
2019-12-10 15:35:44.844388521 +0000
@@ -1,9 +1,9 @@
QA output created by 158
wrote 131072/131072 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
+wrote 65536/65536 bytes at offset 22020096
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-wrote 65536/65536 bytes at offset 9437184
...
(Run 'diff -u xfstests/tests/btrfs/158.out xfstests/results//btrfs/158.out.bad' to see the entire diff)
[CAUSE]
This two tests use physical offset as golden output, while mkfs.btrfs
can do whatever it likes to arrange its chunk layout, thus physical
offset is never reliable.
And btrfs-progs commit c501c9e3b816 ("btrfs-progs: mkfs: match devid
order to the stripe index") just changed the layout.
So the output mismatch and failed.
[FIX]
In fact, that btrfs-progs commit not only changed offset, but also the
device sequence.
So we can't just simply remove the physical offset, but also need to use
proper helper to get both devid (as its device path) and physical offset
for corruption.
As long as mkfs.btrfs still uses sequential devid, these tests should
handle future chunk layout change without problem.
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
[BUG]
When using btrfs-progs v5.4, btrfs/142 and btrfs/143 will fail:
btrfs/142 1s ... - output mismatch (see xfstests/results//btrfs/142.out.bad)
--- tests/btrfs/142.out 2018-09-16 21:30:48.505104287 +0100
+++ xfstests/results//btrfs/142.out.bad
2019-12-10 15:35:40.280392626 +0000
@@ -3,37 +3,37 @@
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
wrote 65536/65536 bytes
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
-XXXXXXXX: aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa ................
...
(Run 'diff -u xfstests/tests/btrfs/142.out xfstests/results//btrfs/142.out.bad' to see the entire diff)
[CAUSE]
Btrfs/14[23] test whether a read on corrupted stripe will re-silver
itself.
Such test by its nature will need to modify on-disk data, thus need to
get the btrfs logical -> physical mapping, which is done by near
hard-coded lookup function, which rely on certain stripe:devid sequence.
Recent btrfs-progs commit c501c9e3b816 ("btrfs-progs: mkfs: match devid
order to the stripe index") changes how we use devices in mkfs.btrfs,
this caused a change in chunk layout, and break the hard-coded
stripe:devid sequence.
[FIX]
This patch will do full devid and physical offset lookup, instead of old
physical offset only lookup.
The only assumption made is, mkfs.btrfs assigns devid sequentially for
its devices.
Which means, for "mkfs.btrfs $dev1 $dev2 $dev3", we get devid 1 for $dev1,
devid 2 for $dev2, and so on.
This change will allow btrfs/14[23] to handle even future chunk layout
change. (Although I hope this will never happen again).
This also addes extra debug output (although less than 10 lines) into
$seqres.full, just in case when layout changes and current lookup can't
handle it, developer can still pindown the problem easily.
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With the snapshot/subvolume support added to fsstress I've been seeing
random failures with our send/receive related tests. This is because
fssum is summing the path with the subvolumes for our test fs'es that
are generated by fsstress. But with send/receive it skips subvolumes,
which makes the sums mismatch. Fix this by skipping directories that do
not match our st_dev, which is how we differentiate subvolumes in btrfs.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Most operations are just looking for a base directory to generate a file
in, they don't actually need a directory specifically. Add FT_ANYDIR to
cover both directories and subvolumes, and then use this in all the
places where it makes sense.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Snapshots are just fancy subvolumes, add this ability so we can stress
snapshot creation. We get the deletion with SUBVOL_DELETE.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This patch adds support to fsstress for creating and deleting subvolumes
on a btrfs file system. We link in the libbtrfsutil library to handle
the mechanics of creating and deleting subvolumes instead of duplicating
the ioctl logic. There is code to check if we're on a btrfs fs at
startup time and if so 0 out the frequency of the btrfs specific
operations.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Nikolay Borisov
Amir Goldstein
Qu Wenruo
Yang Xu
Josef Bacik
Darrick J. Wong
Eric Sandeen
J. Bruce Fields
Johannes Thumshirn
Eric Biggers