Since we're getting rid of the rmapxbt, don't test for it.
Add back the log inode structure.
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 used to retry forever on non-critical errors, and unmount could
hang in such case. Commit e6b3bb78962e ("xfs: add "fail at unmount"
error handling configuration") introduced an error configuration
option in sysfs(fail_at_unmount) and made this behavior
configurable.
Now test this "fail_at_unmount" behavior to make sure XFS doesn't
retry forever on error at unmount time, if configured so. Also
introduced new helpers to require/set/get sysfs attributes.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS has a bug where directory readahead completions can occur after
unmount. This can lead to a crash or panic because metadata read
verification attempts to access core XFS data structures (e.g., the
log) after they have been freed and certain pointers have been
reset.
Add a test that triggers directory readahead, delays the readahead
I/O and immediately unmounts the filesystem. This test is part of
the dangerous group as it will cause kernels affected by the bug to
crash.
[eguan replaced touch with echo to speedup file creation]
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some tests require that there's no certain mount option in
MKFS_OPTIONS, so introduce a new helper
_exclude_scratch_mount_option() to do the check on $MOUNT_OPTIONS.
Also convert generic/192 and xfs/134 to use this helper.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Usually xfs/186 _notrun on crc enabled XFS because of
_require_attr_v1, since v2 attr format is always enabled on v5 XFS.
But when testing on 512B block size XFS, i.e. MKFS_OPTIONS="-m crc=0
-b size=512", test fails. This is because crc enabled XFS was
created in the end, not 512B block size XFS with crc disabled, and
that's not what we want to test.
The reason why _scratch_mkfs_xfs creates a different XFS than
expected is that, it may ignore $MKFS_OPTIONS if mkfs fails due to
conflicts between $MKFS_OPTIONS and the provided mkfs options.
In the case of xfs/186, "-b size=512" conflicts with "-i size=512",
and the first mkfs fails, then it ends up with a 4k block size XFS
with crc enabled (the default config).
Fix it by checking crc enablement status and attr version in the
test, to make sure it's testing on expected XFS.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test 186 won't run when crcs are enabled, because
attrv1 is not allowed with crc=1.
However, ftype is still allowed with crc=0, so
this creates v3 directories, and xfs_db prints
them as such (along with the filetype), which
breaks the test output.
We can filter & replace to fix up the test in
this case.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
A recent test uses the uuidgen utility to generate UUID-based
filenames, but this package is not necessarily installed as part of
the core packages of every distro.
As such, add the UUIDGEN_PROG environment variable to the common
configuration and update the test to require the existence of
uuidgen to run.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some tests use killall command, but killall may not exist.
We should check whether killall exists or not.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If we're running against a old version of xfsprogs that lacks some
of the structures that the golden output knows about, copy the
structure size definition from the golden output to the program
output. This way we can check for structure size mutations on old
xfsprogs without generating false error reports for structs that
don't exist in the old release.
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>
Make sure that we can handle multiple bmbt records mapping to a
single rmapbt record. This can happen if you fallocate more than
2^21 contiguous blocks to a file.
(Also add some helpers that can create huge devices with some
dm-zero and dm-snapshot fakery.)
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>
Ensure that refcountbt allocations during truncate operations come
from the per-AG reservation and are not charged to the transaction.
Reported-by: Christoph Hellwig <hch@lst.de>
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>
Adapt to different metadata overhead sizes by trying to reserve
decreasing amounts of disk space until we actually succeed at it.
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>
XFS had a bug in the multi-block buffer logging code that caused a
NULL lv panic at log push time due to invalid regions being set in
the buffer log format bitmap. This was demonstrated by modifying a
multi-block directory buffer in a manner that only logs regions
beyond the first FSB-sized mapping of the buffer.
To recreate these conditions, this test fragments free space and
populates several directories with enough entries to require
discontiguous multi-block buffers. To recreate the problem, we
remove entries from the tail end of the directory and fsync to flush
the log.
Note that this test causes a panic on kernels affected by the bug.
As such, it is included in the 'dangerous' group. The bug is
resolved by kernel commit a3916e528b91 ("xfs: fix broken multi-fsb
buffer logging").
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Several golden outputs have:
> Note - stripe unit (0) and width (0) fields have been reset.
but it's entirely possible for this to be non-zero,
which then fails to match and fails the test.
Filter this repair output and fix the golden files.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
After GETNEXTQUOTA ioctl being supported, xfs_quota -c "report"
always outputs one more quota line about default quota (as project
ID 0). In order to fix this problem, xfsprogs has merged commit
3d607a1.
Now xfstests face this same problem from this issue. xfs/133 and
xfs/134 can't match their golden output, due to this one more line
quota report output. So this patch filters this redundant quota info
out.
There're 3 kinds of xfsprogs:
1. not support GETNEXTQUOTA
2. support GETNEXTQUOTA but not merged commit 3d607a1
3. the latest version supports all
The 1st one won't report Project ID 0, the 2nd will report projid 0
info as "(null) 0 0 0 ...", the 3rd will report projid 0 info as
"#0 0 0 0 ...". To deal with all of these situations, we will use
_filter_quota | grep -v "^#0 \|^(null) "
But if someone specifies a name for projid 0, e.g.
# cat $projid_file
# root:0
I think that means someone wants to deal with it by himself, the
common filter won't filter it out.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There're many tests don't remove $seqres.full before writing to it, and
accumulating logs there, then the logs are always growing over time.
Let's fix them once.
generic/16[1-8] generic/170 and generic/33[34] truncate $seqres.full in
the middle of the test, which results in partial logs. Fix them as well.
xfs/227 has duplicated lines to remove $seqres.full, remove the extra
line.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
In xfs/299, project IDs are in $tmp.projid file. But there's one
line code try to use $temp.projid. Fortunately, it doesn't bring
any problems until now, but if keep using $temp.projid it really
don't make sense.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Currently xfs/259 tests against TEST_DIR for CRC support status to
decide whether 512 block size should be tested, which is wrong for this
test, because configuration of TEST_DIR is not controlled by test
harness and can be different to the configuration being used in the
test.
Fix it by reversing the block size order that's tested and capture the
output of the actual mkfs command that is being tested, and determine if
512 byte block sizes should be tested based on that output.
While we're at it, I think the test matrix can be enlarged as well, 4k,
2k, 1k and 512 block size can be tested in each fs size boundary, not
only the minimum block size.
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Commit 31f48569c3 ("xfs/030: fix output on newer filesystems") added
more lines to .out file to match the output from XFS with reflink
support, but it broke test on older XFS.
Dave explained the reason and pointed out the correct way to fix it, so
I just quote Dave's mail here:
"The problem here is that reflink triggers a change in the initial
population of the AGFL - from 4 blocks to 6 blocks, and so repair warns
6 times instead of 4. After filtering, that gives 6 indentical output
lines instead of 4.
Doing something as simple as collapsing repeated identical lines (e.g
filtering through uniq) will work for all filesystem formats and any
future changes that modify the initial AGFL population."
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Darrick J. Wong
Zorro Lang
Brian Foster
Eryu Guan
Eric Sandeen
Masayoshi Mizuma