| Age | Commit message (Collapse) | Author |
|---|
|
The write invalidation code in iomap can only be triggered for writes
that span multiple folios. If the kernel reports a huge page size,
scale up the write size.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This function does not follow the naming convention that common helpers
must start with an underscore. Fix this.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This helper has two parts -- querying the value, and _notrun'ing the
test if huge pages aren't turned on. Break these into the usual
_require_hugepages and _get_hugepagesize predicates so that we can adapt
xfs/559 to large folios being used for writes.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I run fstests in a readonly container, and accidentally uninstalled the
btrfsprogs package. When I did, this test started faililng:
--- btrfs/282.out
+++ btrfs/282.out.bad
@@ -1,3 +1,7 @@
QA output created by 282
wrote 2147483648/2147483648 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
+WARNING: cannot create scrub data file, mkdir /var/lib/btrfs failed: Read-only file system. Status recording disabled
+WARNING: failed to open the progress status socket at /var/lib/btrfs/scrub.progress.3e1cf8c6-8f8f-4b51-982c-d6783b8b8825: No such file or directory. Progress cannot be queried
Skip the test if /var/lib/btrfs isn't writable, or if /var/lib isn't
writable, which means we cannot create /var/lib/btrfs.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test is unreliable on NFS. It fails consistently when run vs. a
server exporting btrfs, but passes when the server exports xfs. Since we
don't have any sort of attribute that we can require to test this, just
skip this one on NFS.
Also, subsume the check for btrfs into the _supported_fs check, and add
a comment for it.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
NFS doesn't keep track of whether a file is reflinked or not, so it
doesn't prevent this behavior. It shouldn't be a problem for NFS anyway,
so just skip this test there.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When creating a new dentry (of any type), NFS will optimize away any
on-the-wire lookups prior to the create since that means an extra
round trip to the server. Because of that, it consistently fails this
test.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There are several generic tests that require "setcap", but don't check
whether the underlying fs supports security attrs. Add the appropriate
checks.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test requires FIEMAP support.
Suggested-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Now that I've finally gotten liburing installed on my test machine, I
can actually test io_uring. Adapt these two tests to support
SOAK_DURATION so I can add it to that too.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Ritesh Harjani reported that mount and unmount can race with the xfs cpu
hotplug notifier hooks and crash the kernel, which isfixed by:
https://lore.kernel.org/linux-xfs/ZO6J4W9msOixUk05@dread.disaster.area/T/#t
Extend this test to include that.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Make this test controllable via SOAK_DURATION, for anyone who wants to
perform a long soak test of filesystem vs. cpu hotplug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since commit 3687fcb0752a ("btrfs: zoned: make auto-reclaim less
aggressive"), the reclaim process won't run unless the 75% (by default) of
the filesystem volume is allocated as block groups. As a result, btrfs/237
won't success when it is run with a large volume.
To run the reclaim process, we need to either fill the FS to the desired
level, or make a small FS so that the test write can go over the level.
Since the current test code expects the FS has only one data block group,
filling the FS is both cumbersome and need effort to rewrite the test code.
So, we take the latter method. We create a small (16 * zone size) FS. The
size is chosen to hold a minimal FS with DUP metadata setup.
However, creating a small FS is not enough. With SINGLE metadata setup, we
allocate 3 zones (one for each DATA, METADATA and SYSTEM), which is less
than 75% of 16 zones. We can tweak the threshold to 51% on regular btrfs
kernel config (!CONFIG_BTRFS_DEBUG), but that is still not enough to start
the reclaim process. So, this test requires CONFIG_BTRFS_DEBUG to set the
threshold to 1%.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
xfs_io pwrite issues a series of block size writes, but there is no
guarantee that the resulting extent(s) will be singular or contiguous.
This behavior is acceptable, but the test is flawed in that it expects
a single extent for a pwrite.
Modify test to limit pwrite and reflink to a single block.
Signed-off-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Dave Chinner reported that xfs/273 fails if the AG size happens to be an
exact power of two. I traced this to an agbno integer overflow when the
current GETFSMAP call is a continuation of a previous GETFSMAP call, and
the last record returned was non-shareable space at the end of an AG.
This is the regression test for that bug.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
When the AIO program failed, it is better to bail out the test to keep the
failed state intact.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
I remember this case fails on last year becuase of
kernel commit cae2de69 ("iomap: Add async buffered write support")
kernel commit 1aa91d9 ("xfs: Add async buffered write support").
as below:
pwrite: Resource temporarily unavailable
wrote 8388608/8388608 bytes at offset 0
XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-RWF_NOWAIT time is within limits.
+pwrite: Resource temporarily unavailable
+(standard_in) 1: syntax error
+RWF_NOWAIT took seconds
So For async buffered write requests, the request will return -EAGAIN
if the ilock cannot be obtained immediately.
Here also a discussion[1] that seems generic/471 has been broken.
Now, I met this problem in my linux distribution, then I found the above
discussion. IMO, remove this case is ok and then we can avoid to meet this
false report again.
[Additional information from Dave Chinner]
We changed how timestamps are updated so that they are aware of
IOCB_NOWAIT. If the IOCB_NOWIAT DIO write now needs to update the
inode timestamps, it will return -EAGAIN instead of doing
potentially blocking operations that require IO to complete (i.e.
taking a transaction reservation).
Hence the first time we go to do a DIO read an inode, it's going to
do an atime update, which now occurrs from an IOCB_NOWAIT context
and we return -EAGAIN....
Yes, we added non-blocking timestamp updates as part of the async
buffered write support, but this was a general XFS IO path change of
behaviour to address a potential blocking point in *all* IOCB_NOWAIT
reads and writes, buffered or direct.
The test is not validating that RWF_NOWAIT is behaving correctly - it
just was a simple operation that kinda exercised RWF_NOWAIT semantics
when we had no other way to test this code. It has outlived it's
original purpose, so it should be removed...
[1]https://lore.kernel.org/linux-xfs/b2865bd6-2346-8f4d-168b-17f06bbedbed@kernel.dk/
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The "sort -R" is slower than "shuf" even with the full output because
"sort -R" actually sort them to group the identical keys.
$ time bash -c "seq 1000000 | shuf >/dev/null"
bash -c "seq 1000000 | shuf >/dev/null" 0.18s user 0.03s system 104% cpu 0.196 total
$ time bash -c "seq 1000000 | sort -R >/dev/null"
bash -c "seq 1000000 | sort -R >/dev/null" 19.61s user 0.03s system 99% cpu 19.739 total
Since the "find"'s outputs never be identical, we can just use "shuf" to
optimize the selection.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Use _random_file() helper to choose a random file in a directory.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs supports creating nesting subvolumes however snapshots are not
recurive. When a snapshot is taken of a volume which contains a subvolume
the subvolume is replaced with a stub subvolume which has the same name and
uses inode number 2. This test validates that the stub volume copies
permissions of the original volume.
Signed-off-by: Lee Trager <lee@trager.us>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The mount option "discard=async" is not meant to be used on the zoned mode.
Skip it from the test.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The truncate command in those tests use an uninitialized variable i.
in kdevops, i must contain some leftover, so we get errors like:
/data/fstests-install/xfstests/tests/generic/298: line 45: /dev/loop12):
syntax error: operand expected (error token is "/dev/loop12)")
Apparently, noone including the author of the tests knows why this
truncate command is in the test, so remove the wrong truncate command.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Currently IPC_RMID was attempted on a semid returned after failed
semget() with flags=IPC_CREAT|IPC_EXCL. So nothing was actually removed.
This patch introduces the much more reliable scheme where the wrapper
script creates and removes semaphores, passing a sem key to the test
binary via new -K option.
This patch speeds up the test ~5 times by removing the sem-awaiting
loop in a lock-getter process. As the semaphore is now created before
the test process started, there is no need to wait for anything.
CC: fstests@vger.kernel.org
CC: Murphy Zhou <xzhou@redhat.com>
CC: Jeff Layton <jlayton@kernel.org>
CC: Zorro Lang <zlang@redhat.com>
Signed-off-by: Stas Sergeev <stsp2@yandex.ru>
Reviwed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test is calling _not_run but it should be _notrun, so fix that.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
If the always_cow debugging flag is enabled, all file writes turn into
copy writes. This dramatically ramps up fragmentation in the filesystem
(intentionally!) so there's no point in complaining about fragmentation.
I missed these two in the original commit because readahead for md5sum
would create large folios at the start of the file. This resulted in
the fdatatasync after the random writes issuing writeback for the whole
large folio, which reduced file fragmentation to the point where this
test started passing.
With Ritesh's patchset implementing sub-folio dirty tracking, this test
goes back to failing due to high fragmentation (as it did before large
folios) so we need to mask these off too.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Misspelled variable name. Yay bash.
Fixes: 3e85dd4fe4 ("misc: add duration for long soak tests")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
btrfs/276 creates a 16G file with compression enabled in order to quickly
and efficiently create a file with many extents and have a fs tree with a
height of 3 (root node at level 2), so that it can test that fiemap is
correctly reporting extent sharedness when we have shared subtrees of the
fs tree due to a snapshot.
Compression results in extents with a maximum size of 128K and the test
is expecting only extents of 128K, which normally happens if the machine
has a large amount of RAM and writeback is not triggered before the xfs_io
command finishes. However if writeback is triggered in the meanwhile, due
to memory pressure for example, then we can get end up with some extents
that are smaller than 128K, therefore increasing the total number of
extents in the test file and make the test fail.
This seems to happen often on test machines with small amounts of RAM,
such as 4G, as reported by Qu in the following thread:
https://lore.kernel.org/linux-btrfs/20230801065529.50122-1-wqu@suse.com/
So to address this create a file with holes and direct IO to make sure we
always get a specific number of extents in the test file. To speedup the
test create 2000 64K extents, with holes in between them, so that it works
on a fs with any sector size, and then create a bunch of files with large
xattrs to quickly bump the fs tree height to 3 for any node size (4K to
64K). This also guarantees that the file extent items are spread over
multiples leaves, in order to exercise fiemap's correctness when reporting
shared extents due to shared subtrees.
Reported-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Tested-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Darrick suggests that fstests can provide a simple smoketest, by
running several generic filesystem smoke testing for five minutes
apiece (SOAK_DURATION="5m"). Since there are only five smoke tests,
this is effectively a 20min super-quick test.
With gcov enabled, running these tests yields about ~75% coverage for
iomap and ~60% for xfs; or ~50% for ext4 and ~75% for ext4; and ~45%
for btrfs. Coverage was about ~65% for the pagecache.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Adjust the output of this test to handle the conversion of flexarray
declaration conversions in linux v6.5, commit a49bbce58ea9 ("xfs:
convert flex-array declarations in xfs attr leaf blocks")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test the removal of the underlying device when the file system still
does not have dirty data.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test the removal of the underlying device when the file system still
has dirty data.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a kernel regression caused by commit 75b470332965 ("btrfs:
raid56: migrate recovery and scrub recovery path to use error_bitmap"),
which leads to scrub not repairing corrupted parity stripes.
So here we add a test case to verify the P/Q stripe scrub behavior by:
- Create a RAID5 or RAID6 btrfs with minimal amount of devices
This means 2 devices for RAID5, and 3 devices for RAID6.
This would result the parity stripe to be a mirror of the only data
stripe.
And since we have control of the content of data stripes, the content
of the P stripe is also fixed.
- Create an 64K file
The file would cover one data stripe.
- Corrupt the P stripe
- Scrub the fs
If scrub is working, the P stripe would be repaired.
Unfortunately scrub can not report any P/Q corruption, limited by its
reporting structure.
So we can not use the return value of scrub to determine if we
repaired anything.
- Verify the content of the P stripe
- Use "btrfs check --check-data-csum" to double check
By above steps, we can verify if the P stripe is properly fixed.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
The test case itself is utilizing RAID5/6, which is not yet supported on
zoned device.
In the future we would use raid-stripe-tree (RST) feature, but for now
just reject zoned devices completely.
And since we're here, also update the _fixed_by_kernel_commit lines, as
the proper fix is already merged upstream.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Although btrfs has a per-fs feature directory, it's not properly
refreshed after new features are enabled.
We had some attempts to do that properly, like commit 14e46e04958d
("btrfs: synchronize incompat feature bits with sysfs files").
But unfortunately that commit get later reverted as some call sites is
not safe to update sysfs files.
Now we have a new commit b7625f461da6 ("btrfs: sysfs: update fs features
directory asynchronously") to properly refresh that per-fs features
directory.
So it's time to add a test case for it. The test case itself is pretty
straightforward:
- Make a very basic 3 disks btrfs
Only using the very basic profiles (DUP/SINGLE) so that even older
mkfs.btrfs can support.
- Make sure per-fs features directory doesn't contain "raid1c34" file
- Balance the metadata to RAID1C3 profile
- Verify the per-fs features directory contains "raid1c34" feature file
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
[ Update commit log. Remove commented code. Add _fixed_by_kernel_commit.
Check mkfs status. Add sync. ]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
The test case would reproduce the situation by creating an empty fs,
with SINGLE metadata profile, then corrupt the tree root manually.
Finally try mounting the corrupted fs, the mount should fail while our
kernel should not fail.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
[ Update commit log. Fix a line gt 80 chars. Use append to $seqres.full.
Fix comment ]
Signed-off-by: Anand Jain <anand.jain@oracle.com>
|
|
There is a recent regression during v6.4 merge window, that a u32 left
shift overflow can cause problems with large data chunks (over 4G)
sized.
This is especially nasty for RAID56, which can lead to ASSERT() during
regular writes, or corrupt memory if CONFIG_BTRFS_ASSERT is not enabled.
This is the regression test case for it.
Unlike btrfs/292, btrfs doesn't support trim inside RAID56 chunks, thus
the workflow is simplified:
- Create a RAID5 or RAID6 data chunk during mkfs
- Fill the fs with 5G data and sync
For unpatched kernel, the sync would crash the kernel.
- Make sure everything is fine
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Mikulas reported that this test became a forkbomb on his system when he
tested it with bcachefs. Unlike XFS and ext4, which have large inodes
consuming hundreds of bytes, bcachefs has very tiny ones. Therefore, it
reports a large number of free inodes on a freshly mounted 1GB fs (~15
million), which causes this test to try to create 15000 processes.
There's really no reason to do that -- all this test wanted to do was to
exhaust the number of inodes as quickly as possible using all available
CPUs, and then it ran xfs_repair to try to reproduce a bug. Set the
number of subshells to 4x the CPU count and spread the work among them
instead of forking thousands of processes.
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Tested-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Bill O'Donnell <bodonnel@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add some tests to make sure that userspace and the kernel actually
agree on how to do ascii case-insensitive directory lookups, and that
metadump can actually obfuscate such filesystems.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This tests that the right xattrs are set during copy-up, and
that we properly fail on missing of erronous fs-verity digests
when validating.
We also ensure that verity=require fails if a metacopy has not
fs-verity, and doesn't do a meta-coopy-up if the base file lacks
verity.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add test coverage for following metacopy from lower layer to
data-only lower layers.
Data-only lower layers are configured using the syntax:
lowerdir=<lowerdir1>:<lowerdir2>::<lowerdata1>::<lowerdata2>.
Test that lowerdata files can be followed only by absolute redirect
from lower layer.
Test that with two lowerdata dirs, we can lookup individual lowerdata
files in both, and that a shared file is resolved from the uppermost
lowerdata dir.
There is also test case for lazy-data lookups, where we remove the
lowerdata file and validate that we get metadata from the metacopy
file, but open fails.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Add test coverage for following metacopy from lower layer to
lower data with absolute, relative and no redirect.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Create a new test to make sure that growfs on the realtime device works
without corrupting anything.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since we're testing growfs of the data device, we should create the
files there, even if the mkfs configuration enables rtinherit on the
root dir.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
An upcoming patch moves more log validation checks to the superblock
verifier, so update this test as needed.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
This test examines the behavior of mkfs.xfs with specific filesystem
configuration files by formatting the scratch device directly with those
exact parameters. IOWs, it doesn't include external log devices or
realtime devices. If external devices are set up, the post-test fsck
run fails because the filesystem doesnt' use the (allegedly) configured
external devices. Fix that by adding _require_scratch_nocheck.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
If I have a realtime volume configured, this test will sometimes trip
over this:
XFS: Assertion failed: nmaps == 1, file: fs/xfs/xfs_dquot.c, line: 360
Call Trace:
xfs_dquot_disk_alloc+0x3dc/0x400 [xfs 97e1fa8953d397b1fb9732df4de7fa9070bda501]
xfs_qm_dqread+0xc9/0x190 [xfs 97e1fa8953d397b1fb9732df4de7fa9070bda501]
xfs_qm_dqget+0xa8/0x230 [xfs 97e1fa8953d397b1fb9732df4de7fa9070bda501]
xfs_qm_vop_dqalloc+0x160/0x600 [xfs 97e1fa8953d397b1fb9732df4de7fa9070bda501]
xfs_setattr_nonsize+0x318/0x520 [xfs 97e1fa8953d397b1fb9732df4de7fa9070bda501]
notify_change+0x30e/0x490
chown_common+0x13e/0x1f0
do_fchownat+0x8d/0xe0
__x64_sys_fchownat+0x1b/0x20
do_syscall_64+0x2b/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7fa6985e2cae
The test injects the bmap_alloc_minlen_extent error, which refuses to
allocate file space unless it's exactly minlen long. However, a
precondition of this injection point is that the free space on the data
device must be sufficiently fragmented that there are small free
extents.
However, if realtime and rtinherit are enabled, the punch-alternating
call will operate on a realtime file, which only serves to write 0x55
patterns into the realtime bitmap. Hence the test preconditions are not
satisfied, so the test is not serving its purpose.
Fix it by disabling rtinherit=1 on the rootdir so that we actually
fragment the bnobt/cntbt as required.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
There is a recent regression during v6.4 merge window, that a u32 left
shift overflow can cause problems with large data chunks (over 4G
sized).
This is the regression test case for it.
The test case itself would:
- Create a RAID0 chunk with a single 6G data chunk
This requires at least 6 devices from SCRATCH_DEV_POOL, and each
should be larger than 2G.
- Fill the fs with 5G data
- Make sure everything is fine
Including the data csums.
- Delete half of the data
- Do a fstrim
This would lead to out-of-boundary trim if the kernel is not patched.
- Make sure everything is fine again
If not patched, we may have corrupted data due to the bad fstrim
above.
For now, this test case only checks the behavior for RAID0.
As for RAID10, we need 12 devices, which is out-of-reach for a lot of
test envionrments.
For RAID56, they would have a different test case, as they don't support
discard inside the RAID56 chunks.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Test that if we have a subvolume with a non-active swap file, we can not
activate it if there are any snapshots. Also test that after all the
snapshots are removed, we will be able to activate the swapfile.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
Since v6.3, I noticed that generic/604 does not run on overlayfs
because:
generic/604 -- upper fs needs to support d_type
This is odd because the base fs I am using (xfs) does support d_type.
The reason is that for overlayfs, this sequence run by this test:
_scratch_unmount &
_scratch_mount
Translates to:
umount $OVL_MNT; umount $BASE_MNT &
mount $BASE_MNT ...; mount $OVL_MNT ...
Which can end up reordred as:
umount $OVL_MNT;
mount $BASE_MNT ...
umount $BASE_MNT &
mount $OVL_MNT ...
and overlayfs is trying to use a non-existing upper fs.
Use UMOUNT_PROG directly instead of the _scratch_unmount
helper, to avoid unmounting the base fs.
Incidently, the only thing that has changed in overlayfs in v6.3
is idmapped mounts support and the test in question was run without
idmapped mounts enabled, so the cahnge in behavior must be related
to some subtle timing change.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
|
For ceph fuse client the fs type will be "ceph-fuse".
Fixes: https://tracker.ceph.com/issues/61496
Signed-off-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>
|
