Verify kernel doesn't panic when user attempts to set realtime flags
on non-realtime FS, using kernel compiled with CONFIG_XFS_RT.
Unpatched kernels will panic during this test. Kernels not compiled
with CONFIG_XFS_RT should pass test.
This bug was fixed via commit b31ff3cdf540 ("xfs:
XFS_IS_REALTIME_INODE() should be false if no rt device present") on
the main kernel tree.
[eguan: don't assume fixed position when grepping 't' and add some
comments about why we do this, also remove testfile after test]
Signed-off-by: Richard Wareing <rwareing@fb.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If we got over the bmbt length we'll always allocate two extents,
its just that so far getbmap merged them.
Also fix/update some comments.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Tests the search algorithm for a free inode slot in a specific AG,
done in xfs_dialloc_ag_inobt().
When finobt is not used, and agi->freecount is not 0, XFS will scan
the AG inode tree looking for a free inode slot, but if
agi->freecount is corrupted, and there is no free slot at all, it
will end up in an infinite loop.
This test checks for the infinite loop fix.
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Make sure that we update the rmapbt correctly when we collapse-range
a file and the extents on both sides of the hole can be merged. We
can construct this pretty trivially with insert-range and write, so
test that too.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The size of the structure used to retrieve per-AG reserved blocks
status has changed (it's not in a released upstream), so update
xfs/122.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
In this test, the cleaner thread deletes the directory trees created
by fsstress in order to exercise the free inode btree code.
However, if fsstress dies, the cleaner can end up waiting forever
for a directory that will never be created, which hangs up the test
run. Therefore, abort if fsstress has ended.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
These two tests simulate log failure during a reflink operation.
However, the contents of the target of the reflink operation depend
on the block size, so we cannot hardcode md5 hashes in this test.
Since the whole point of the test is to ensure that the the complex
chain of transactions actually finishes no matter where the
interruption, it is sufficient simply to run the usual end-of-test
fsck to look for corrupt metadata.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs/095 fails on 4k hard sector size device, due to it runs:
_mkfs_log "-l version=1 -m crc=0 -d sectsize=512"
So _notrun if SCRATCH_DEV's sector size is bigger than 512b.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Ensure that the fuzz command does what it says.
[eguan: fixed test failures on non-CRC XFS]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS is susceptible to log recovery problems if the fs crashes under
certain circumstances. If the tail has been pinned for long enough
to the log to fill and the next batch of log buffer submissions
happen to fail, the filesystem shuts down having potentially
overwritten part of the range between the last good tail->head range
in the log. This causes log recovery to fail with crc mismatch or
invalid log record errors.
Add a test that uses XFS DEBUG mode error injection to force the
tail overwrite condition with a known bad (crc mismatch) log write
and tests that log recovery succeeds. Note that this problem is
currently only reproducible with larger (non-default) log buffer
sizes (i.e., '-o logbsize=256k') or smaller block sizes (1k).
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
1) This test can check if setting types causes error regardless of
supporting crc, so we can update existed comments about it. We
also add new comments about known issues triggered in this test.
2) When finobt is disabled, xfs_db fails to get current address of
free_root, as below:
xfs_db -c "agi" -c "addr free_root" -c "daddr" /dev/sda11
Metadata CRC error detected at xfs_inobt block 0x0/0x1000
...
Running related tests without finobt makes no sense, so we add
check for finobt.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Refactor the XFS error injection helpers to use the new errortag
interface to configure error injection. If that isn't present, fall
back either to the xfs_io/ioctl based injection or the older sysfs
knobs. Refactor existing testcases to use the new helpers.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs_db should take type size into account when setting type.
If type size isn't updated whenever type is set, a false crc
error can occur due to the stale size. This test checks for
that false crc error.
Signed-off-by: Bill O'Donnell <billodo@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
I added some new operatoins to fsstress, and it changed the total
number of test operstions.
xfs/068 use a fixed seed (-s) and number of operations (-n) to run
fsstress, to get fixed number of files and directories. Due to my
patches break these fixed things, so update its expected result in
golden image.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some tests had separate output files for IRIX and Linux. Now that the
IRIX ones have been removed, rename the Linux ones and remove the
now-unneeded .cfg files and calls to _link_out_file.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Many tests claimed (via _supported_os) to work on both Linux and IRIX.
Since IRIX is no longer supported by xfstests, update these to claim
Linux support only. Then remove any obvious IRIX-specific logic in the
tests, and any IRIX-specific golden output files.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
These two IRIX and XFS-specific tests were just placeholders which
didn't actually test anything. It also seems they were meant to use the
acl_get and acl_test programs, but those weren't even being compiled.
Get rid of all this unused stuff.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
These two IRIX and XFS-specific tests tested the "parent pointer"
feature which is not implemented by XFS on Linux. Just remove them.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This tests upgrading the XFS log to v2. Switch from the IRIX xfs_chver
program to xfs_db.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs/297 formats the scratch device with test specific mkfs options
that limit the use of certain mount options (i.e., if logbsize !=
256k). If an incompatible mount option is set, the mount fails but
the test proceeds to run against the root filesystem.
Update xfs/297 to fail if the mount of the scratch device fails for
whatever reason.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
It turns out that there was a bug in xfs_bmap_count_blocks wherein
the block count returned would count or not count delalloc blocks
depending on the fork format. This is a bug that is easily exposed
via scrub, so check the output of that function here -- the buggy
version of the function produces online fsck errors.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The rmapbt repair code plays some dirty tricks with the fs freezer
to avoid running afoul of regular xfs locking requirements. Add a
test to check that filesystem write activities do not deadlock with
the repair program.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs_io's fsmap command flipped the attrfork and shared bits, so we
have to change them here too.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Richard Wareing
Christoph Hellwig
xiao yang
Carlos Maiolino
Darrick J. Wong
Zorro Lang
Brian Foster
Bill O'Donnell
Eric Biggers