I'm really not sure why this wasn't this way from the start.
On some systems it's in /usr/sbin, and the test fails.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Changes in the XFS logging code have lead to small leaks in the log
grant heads that consume log space slowly over time. Such problems have
gone undetected for an unnecessarily long time due to code complexity
and potential for very subtle problems. Losing only a few bytes per
logged item on a reasonably large enough fs (10s of GB) means only the
most continuously stressful workloads will cause a severe enough failure
(deadlock due to log reservation exhaustion) quickly enough to indicate
something is seriously wrong.
Recent changes in XFS export the state of the various log heads through
sysfs to aid in userspace/runtime analysis of the log. This test runs a
workload against an XFS filesystem, quiesces the fs and verifies that
the log reserve and write grant heads have not leaked any space with
respect to the current head of the physical log.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS can allocate significant amounts of space to files via speculative
preallocation. Such preallocation may not be reclaimed automatically on
file close() if a file is repeatedly opened and extended. For smaller
filesystems with relatively large and slow growing files, this
preallocation can linger for some time, including contributing to out of
space conditions.
Create a situation where an fs is near out of space while several files
still have lingering, significant preallocations. Verify that new
writers reclaim the preallocated space rather than return ENOSPC. Repeat
a similar test for quota limits and EDQUOT.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
It has been reported that test xfs/013 probably uses more space than
necessary, exhausting space if run against a several GB sized ramdisk.
xfs/013 primarily creates, links and removes inodes. Most of the space
consumption occurs via the background fsstress workload.
Remove the fsstress -w option that suppresses non-write operations. This
slightly reduces the storage footprint while still providing a
background workload for the test.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Failure message of mount has been changed since util-linux v2.21, to
something like:
mount: mount /dev/sda5 on /mnt/scratch failed: Structure needs cleaning
Filter the output to match the golden image for newer mount binary so
that both old and new version of mount work correctly.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Several tests happen to make use of loop device support without the
requisite pre-test checks. This results in spurious failures for systems
that might not have loop device support. Add _require_loop checks to
shared/298, xfs/206 and xfs/259.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Kill any lingering fsstress processes and wait properly should we abort
the test. This prevents the workload from inadvertently affecting
subsequent tests.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Create a stress test for the free inode btree. Allocate a set of inodes
sequentually and run a hard link clone and random replacement algorithm
across the set. Background removal of the oldest directories creates a
sparse set of free inodes over time. Run an fsstress workload
concurrently to exercise the fs.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The finobt creates a duplicate subset of inode allocation metadata from
the inobt. xfs_repair should detect and repair inconsistencies in the
finobt that could be caused by bugs or corruption. This test uses xfs_db
to cause targeted corruptions in the finobt and verify repair detects
and corrects the filesystem.
In particular, the test corrupts individual finobt records to cause
inconsistency between the inode allocation count fields as well as
causing the finobt to contain a record with no free inodes.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs/030 nukes various on-disk data structures to test for repair. This
can result in extra output when testing finobt enabled filesystems. For
example, xfs_repair detects an invalid free inode btree root block when
the agi is zeroed.
Filter this output directly in xfs/030 such that the test passes for
finobt and non-finobt filesystems.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Number of helpers for checking xfs_io functionality is slowly
growing. But it's as easy to simply use _require_xfs_io_command()
directly and just specify the command we want to check. It will also
avoid the need to create helper every time we need to check a new
command in xfs_io.
Remove all the helpers and use _require_xfs_io_command() in the
tests.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
There is no mainline kernel support for DMAPI in XFS, and so every
time the xfstests auto group is run it throws a large number of
"[not run] Assuming DMAPI modules are not loaded". I've noted that
people are excluding the dmapi group to avoid this, so rather than
inflict pain on everyone, make hose few that need to do dmapi
testing include it specifically.
IOWs, remove the DMAPI tests from the auto group.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
A couple of tests leave behind large files or directory structures
when they complete, which leads to small TEST_DEVs running out of
space during other tests. Make those space hogs clean up after
themselves so that random tests don't fail with ENOSPC errors.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When running on a ramdisk, the fsstress background workload consumes
a GB of disk space every 5 seconds. This leads to the test failing
with ENOSPC because the test file cannot be created due otthe
background load cosuming it all. Hence don't run this test unless
the scratch device is large enough not to hit ENOSPC conditions.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The Q_XQUOTARM quotactl was not working properly, because
we weren't passing in proper flags. The xfs_fs_set_xstate()
ioctl handler used the same flags for Q_XQUOTAON/OFF as
well as Q_XQUOTARM, but Q_XQUOTAON/OFF look for
XFS_UQUOTA_ACCT, XFS_UQUOTA_ENFD, XFS_GQUOTA_ACCT etc,
i.e. quota type + state, while Q_XQUOTARM looks only for
the type of quota, i.e. XFS_DQ_USER, XFS_DQ_GROUP etc.
Unfortunately these flag spaces overlap a bit, so we
got semi-random results for Q_XQUOTARM; i.e. the value
for XFS_DQ_USER == XFS_UQUOTA_ACCT, etc. yeargh.
Anyway, here's a simple test that demonstrates it,
kernel patch to fix it will follow.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test was written before a solution was in place, I think,
and so the expected output wasn't well tested.
The test does a loop of sparse writes from 6 to 0, but the
.out file expects 6 (not 7) extents. Fix it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Create new function _test_block_boundaries() which is testing content of
the blocks after the operation such as zero, or punch hole. The test is
doing the operation around block boundaries to assure correct behaviour
of the operation on block unaligned ranges.
This has been based on test xfs/290 which has been changed to use this
new function. A small change to the output file was required.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When running on a ramdisk, the fsstress background workload consumes
a GB of disk space every 5 seconds. This leads to the test failing
with ENOSPC because the test file cannot be created due otthe
background load cosuming it all. Hence don't run this test unless
the scratch device is large enough not to hit ENOSPC conditions.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
I'm running xfstests against a ramdisk, so I'm limited in size of
the test and scratch devices. While there are large enough to hold a
filesystem image with a 2GB log, the way the log changes position in
an image file as the size of the filesystem increases means that the
aggregated disk space of xfs/217 is more than enough to run a 4GB
TEST_DEV out of space and hence fail the test.
To avoid this problem, punch out the image file between every mkfs
iteration so that it only consumes the space needed by each
individual mkfs tests, not an aggregation of them all.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Version 5 filesystems always have attr2 format enabled, and it
cannot be turned off via the noattr2 mount option. As such, attempts
to mount with noattr2 will be rejected and this causes cascading
failures within the test.
Hence detect if we've created a CRC enabled filesystem, and if this
is the case _notrun the test.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
CRC enabled filesystems emit different errors on corruption.
Specifically, inode corruption is picked up much earlier due to
verifier failures (e.g. incorrect inode identifier) and so
xfs_repair throws errors sufficiently different that filtering
cannot hide the differences. Hence simply add a new golden output
file and link it appropriately once we know what type of filesystem
we are testing.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
the commit:
10e6e65 xfs: be more forgiving of a v4 secondary sb w/ junk in v5 fields
broke primary sb CRC validation, not erroring out the mount
if the crc was bad.
This tests that it's fixed, and properly fails the mount on
a bad crc.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test that we properly ignore old growfs-induced junk in the unused
portion of secondary V4 superblocks; at one point this would
trip up the verifiers, and cause a subsequent growfs to fail.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test the setting of the XFS BMBT fields via xfs_db. Runs through the
valid bit values for each field and tests an illegal value.
[dchinner: added _require_xfs_mkfs_crc and turned off crcs so that
the test doesn't just fail on CRC enabled test runs.]
[dchinner: added hex block values to check they don't get endian
swapped.]
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>