Overlayfs introduces some complexity with regards to what path we have
to use to shut down the scratch filesystem: it's SCRATCH_MNT for regular
filesystems, but it's OVL_BASE_SCRATCH_MNT (i.e. the lower mount of the
overlay) if overlayfs is enabled. The helper works through all that, so
we might as well use it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
So it turns out that overlayfs can't pass FS_IOC_SHUTDOWN to the lower
filesystems and so xfstests works around this by creating shutdown
helpers for the scratch fs to direct the shutdown ioctl to wherever it
needs to go to shut down the filesystem -- SCRATCH_MNT on normal
filesystems and OVL_BASE_SCRATCH_MNT when -overlay is enabled. This
means that t_open_tmpfiles cannot simply use one of the open tempfiles
to shut down the filesystem.
Commit f8f5774722 tried to "fix" this by ripping the shutdown code out,
but this made the tests useless. Fix this instead by creating a
xfstests helper to return a path that can be used to shut down the
filesystem and then pass that path to t_open_tmpfiles so that we can
shut down the filesystem when overlayfs is enabled.
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>
Commit f8f5774722 ("generic/530: fix shutdown failure of generic/530 in
overlay") improperly clears an overlayfs test failure by shutting down
the filesystem after all the tempfiles are closed, which totally defeats
the purpose of both generic/530 and xfs/501. Revert this commit so we
can fix it properly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Testcases are recommended to use _require_scratch_shutdown()
and _scratch_shutdown() pair helper function to test and execute
shutdown.
generic/530 formmerly used _require_scratch_shutdown() to test
whether the filesystem supports shutdown or not, while executed
the shutdown action in a raw binary (src/t_open_tmpfiles) rather
than the recommended _scratch_shutdown() helper. This will cause
a "shutdown: Inappropriate ioctl for device" error message when
testing overlay filesystem.
This patch simply move the shutdown action from the raw binary
into the packaged _scratch_shutdown() helper. That is, we remove
the "shutdown" interface of t_open_tmpfiles.c and call
_scratch_shutdown() in genric/530 and xfs/501.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test requires us to fragment free space, and in part accomplishes
this by fallocating 400M of a 512M filesystem, then fallocating another
70M, and then using dd to eat remaining space. However, it's risky to
assume the 400M figure because new features such as reflink and rmap
have per-ag metadata reservations which add to overhead. Therefore,
reserve the 70M fragment file first, then try to fallocate 95% of the
remaining free space.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test seems to check that log sizes scale up properly with the size
of the filesystem, given a carefully controlled set of mkfs parameters.
Since turning on reflink or rmap will change the minimum log size,
change the test to detect their presence and ensure they're disabled.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a new helper function to discover the minimum log size that will
work with the mkfs options provided, then remove all the hardcoded block
sizes from various xfs tests. This will be necessary when we turn on
reflink or rmap by default and the minimum log size increases.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Commit "8309b39a fstests: fix broken _require_scratch usage" did
below change on xfs/065:
-_scratch_unmount 2>/dev/null
+_scratch_mkfs_xfs >> $seqres.full
It cause xfs/065 always fails now, as:
QA output created by 065
mkfs.xfs: /dev/sdb2 contains a mounted filesystem
...
So use _require_scratch, to make sure the SCRATCH_DEV is unmounted
before mkfs.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure that copy, metadump, and mdrestore work on a filesystem with
all known metadata types.
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>
_require_scratch doesn't actually format the scratch device with
anything, which means that tests are required to format them before
using them. Fix tests that don't do this correctly.
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>
The way we decided if an unwritten extent is considered a hole or
data is by checking if the page and/or blocks are marked uptodate,
that is contain valid data in the page cache.
xfs/420 and xfs/421 try to exercise SEEK_HOLE / SEEK_DATA in the
presence of cowextsize preallocations over holes in the data fork.
The current XFS code never actually uses those for buffer writes,
but a pending patch changes that. For SEEK_HOLE / SEEK_DATA to work
properly in that case we also need to look at the COW fork in their
implementations and thus have to rely on the unwritten extent page
cache probing. But the tests for it ensure we do have valid data in
the pagecache by calling md5sum on the test files, and thus reading
their contents (including the zero-filled holes) in, and thus making
them all valid data.
Fix that by dropping the page cache content after the md5sum calls.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For the t_open_tmpfiles tests, limit ourselves to half of file-max
so that we don't OOM the test machine.
[Eryu: fix comments too to match the new limit]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
No dedup functionality is exercised by these tests.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test needs to check for working falloc command before using it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a test (+ helper program) that opens as many unlinked files as it
possibly can on the scratch filesystem, then closes all the files at
once to stress-test unlinked file cleanup. Add an xfs-specific test to
make sure that the fallback code doesn't bitrot.
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>
This test has the number of files/dirs created by xfsrestore hardcoded
in golden output.
When fsstress is added new ops, the number of files/dirs created with
the same random seed changes and this regularly breaks this test,
so when new fsstress ops are added they should be either added to the
dump test blacklist or golden output of this test needs to be ammended
to reflect the change.
The golden output includes only the file count reported by xfsrestore
and test does not even verify that this is the correct file count.
Instead, leave the golden output neutral and explicitly verify that
file count before and after the test are the same.
With this change, the test becomes agnostic to fsstress ops and we
could also stop blacklisting clone/dedup/copy ops if we want.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
xfs/252 has a few feature tests, but misses checking for preallocation
support. Because of that it will fail instead of not being run for
and XFS file system in always COW mode.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Instead, call _cleanup_dump explicitly from a private _cleanup.
Remove the generic cleanup bits (rm $tmp.*) from _cleanup_dump.
The only xfs/dump test that had anything other than rm $tmp.* in
_cleanup in xfs/287, but that was _scratch_unmount, which is not
needed anyway.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Format the scratch device before using it, or else xfs_db will fail,
particularly if the previous test left a corrupt fs behind.
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>
Make sure that we still have the scratch directory after repairing our
corrupted filesystem, because repair could have nuked it.
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>
x/139 and x/140 makes XFS with very small agsize. That agsize is too
small for a large fs. And it's not necessary to test on large fs, so
skip it directly if scratch dev is large dev.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Jeffle Xu
Zorro Lang
Christoph Hellwig
Amir Goldstein