xfs/030 always fails after d0e484ac69 ("check: wipe scratch devices
between tests") get merged.
Due to xfs/030 does a sized(100m) mkfs. Before we merge above commit,
mkfs.xfs detects an old primary superblock, it will write zeroes to
all superblocks before formatting the new filesystem. But this won't
be done if we wipe the first superblock(by merging above commit).
That means if we make a (smaller) sized xfs after wipefs, those *old*
superblocks which created by last time mkfs.xfs will be left on disk.
Then when we do xfs_repair, if xfs_repair can't find the first SB, it
will go to find those *old* SB at first. When it finds them,
everyting goes wrong.
So I try to wipe each XFS superblock if there's a XFS ondisk, then
try to erase superblock of each XFS AG by default mkfs.xfs geometry.
Thanks Darrick J. Wong helped to analyze this issue.
Reported-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
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>
When running overlay tests using character devices as base fs partitions,
all overlay usecase results become 'notrun'. Function
'_overay_config_override' (common/config) detects that the current base
fs partition is not a block device and will set FSTYP to base fs. The
overlay usecase will check the current FSTYP, and if it is not 'overlay'
or 'generic', it will skip the execution.
For example, using UBIFS as base fs skips all overlay usecases:
FSTYP -- ubifs # FSTYP should be overridden as 'overlay'
MKFS_OPTIONS -- /dev/ubi0_1 # Character device
MOUNT_OPTIONS -- -t ubifs /dev/ubi0_1 /tmp/scratch
overlay/001 [not run] not suitable for this filesystem type: ubifs
overlay/002 [not run] not suitable for this filesystem type: ubifs
overlay/003 [not run] not suitable for this filesystem type: ubifs
When checking that the base fs partition is a block/character device,
FSTYP is overwritten as 'overlay'. This patch allows the base fs
partition to be a character device that can also execute overlay
usecases (such as ubifs).
Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/564 wants to test for copy_range -f, but as it's implemented
it calls copy_range with a length of zero which will silently return
success from the VFS (at least on some kernels) even if the underlying
fs doesn't support it.
So patch this up 2 ways; perform the test with an explicit length
so it's not a no-op, and go ahead test copy_range w/o -f in the test
first just to be on the safe side (and for clearer failure messages.)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
CephFS currently has only a very primitive SEEK_HOLE implementation,
and always sets the offset to EOF when it's used. Remove it from the
whitelist.
Cc: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Implement "_require_xfs_io_command copy_range -f" to check for
the option added by following xfsprogs commit:
10d4ca4aeff5 ("xfs_io: allow passing an open file to copy_range")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
f2fs can support FS_IOC_{GET,SET}FSLABEL now, set max label length
to enable generic/492 testcase for f2fs.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The kernel version (uname -v) may also be needed in addition to
the kernel release (uname -r) in order to properly identify and
distinguish different kernel builds in some cases/distributions.
For example, in the Ubuntu kernel package the test/debug string
is usually a suffix to the version field, not the release field.
$ uname -rv
4.15.0-51-generic #55-Ubuntu SMP Wed May 15 14:27:21 UTC 2019
$ uname -rv
4.15.0-51-generic #55+test20190520b1 SMP Mon May 20 11:57:40 -03 2019
Looking at other OSes uname(1) man pages it looks like '-v' is
quite standard, and the Linux man page only cites '-p' and '-i'
as non-portable, so the change should be OK. The only caller is
the 'check' script for the header print out, so it's contained.
Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The shared/006 uses _scratch_mkfs_sized to create a limited size
file system, and then creates inodes until it gets ENOSPC, and then
checks to make sure the file system is consistent. It then remounts
the file system, removes all of the files, and makes sure the file
system is consistent afterwards. This test was marked as only being
supported on ext[234] and xfs, and so it was in shared.
Now introduce a new _require_inode_limits() rule to run test on
filesystems that have a fixed inode number, then move the test to
generic.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With "_require_xfs_io_command chattr <letter>", check that
flag can be set/cleared using FS_IOC_FSSETXATTR ioctl, similar
to "_require_chattr <letter>" and FS_IOC_SETFLAGS ioctl.
Update the documentation and the tests that use
"_require_xfs_io_command chattr" to test filesystem support
and not only xfs_io support.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In _require_xfs_io_command, when command fails for one of the
generic reasons, if command was tested with params, print out
the params of the failed command.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
_repair_scratch_fs did not do the right thing for overlay.
Implement and call _repair_overlay_scratch_fs to repair
overlay filesystem and then fall through to repair base filesystem.
The only tests currentrly calling _repair_scratch_fs on a
./check -overlay run are generic/330 generic/332 in case the
base fs supports reflink. The rest of the tests calling
_repair_scratch_fs require that $SCRATCH_DEV is a block device.
Suggested-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
_dump_err2() helper was introduced over two years ago and it broke
the error reporting from _repair_scratch_fs.
Every test that runs:
_repair_scratch_fs >> $seqres.full
and expect to fail if anything is written to stderr is not working
as intended.
Reported-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.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 34081087 adds more sanity to seek_sanity_test() to prevent
a lseek() implementation regression from being ignored, and a
hardcoded whitelist is maintained to distinguish whether a
filesystem type only supports non-default behavior of SEEK_HOLE
or not.
In commit 34081087, NFS is listed in this whitelist, that is, NFS
is thought supporting non-default behavior only. However as far as
I know, nfsv2 and nfsv3 only support default behavior of SEEK_HOLE
(that is, always returning EOF) in linux.
On the other hand, xfstests uses "mount -t nfs ..." to mount a
NFS mount point. Normally the mount point is mounted as nfsv4,
but it can be mounted mandatorily as nfsv3 if we specify
"Nfsvers=3" in /etc/nfsmount.conf. In this case, a series of
tests fail (including generic/285, generic/448, generic/490, etc.)
with error message "Default behavior is not allowed. Aborting."
So I just make some special handling for NFS in
_fstyp_has_non_default_seek_data_hole(), that is, default behavior
of SEEK_HOLE is acceptable for nfsv2 and nfsv3.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Ignore lockdep complaining about its own bugginess when scanning dmesg
output, because we shouldn't be failing filesystem tests on account of
lockdep.
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>
Wipe the scratch devices in between each test to ensure that tests are
formatting them and not making assumptions about previous contents.
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>
When call _scratch_remount for cifs , it always requires to input
password. This will make generic/306 generic/452 failed because
cifs remount failed.
Signed-off-by: Xiaoli Feng <xifeng@redhat.com>
Reviewed-and-tested-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
seek_sanity_test checks for one of several SEEK_DATA/HOLE
behaviors and allows for the default behavior of filesystems,
where SEEK_HOLE always returns EOF.
This means that if filesystem has a regression in finding
holes, the sanity test won't catch it. And indeed this regression
happened in overlayfs on kernel v4.19 and went unnoticed.
To improve test coverage, add a flag -f to seek_sanity_test to
indicate that the default behavior is not acceptable.
Whitelist all filesystem types that are expected to detect holes
and use wrapper when invoking seek_sanity_test to add the -f flag
to those filesystems.
Overlayfs inherits expected behavior from base fs type.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Acked-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For a long time this test has been failing on all kinds of VM
configuration, which are using virtio_blk devices. This is due to
the fact that scsi devices are deletable and virtio_blk are not.
However, this only prevents device replace case to run and has no
negative effect on the other useful test cases.
Re-enable btrfs/003 to run by making
_require_deletable_scratch_dev_pool private to the test case and
modifying it to return success (0) or failure (1) if devices are not
deletable. Further modify the replace test case to check the return
value of this function and skip it if devices are not deletable.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Helper functions are supposed to have a leading underscore ('_') in the
function name, but this one doesn't have it. Unfortunately, the calling
test cases (generic/349-351) /do/ have the leading underscore, so now
they're broken.
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>
For some filesystem, such as vfat, the max support file size is 4G.
We limit the max size and let the test go on running.
Fix it by moving the function get_max_file_size() of generci/485 to
common/rc, and add the max filesize limit to generic/299.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filesystems are not required to try to fill the statx btime field
unless the caller actually sets STATX_BTIME. They're allowed to
volunteer that information "if it's cheap", but XFS doesn't
volunteer and there may be filesystems that support btime but not
cheaply.
Either way, we want to test btime on any filesystem that supports
it, cheaply or otherwise, so set STATX_BTIME when we're trying to
detect support for it.
[Eryu: fix _require_scratch_btime too]
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>
Zorro Lang
Zhihao Cheng
Eric Sandeen
Jeff Layton
Amir Goldstein
Chao Yu
Mauricio Faria de Oliveira
Theodore Ts'o
Darrick J. Wong
Jeffle Xu
Xiaoli Feng
Nikolay Borisov
Yufen Yu