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>
1) This pattern is repeated in several seek_data/hole tests
(e.g. generic/285, generic/436, generic/445 generic/448)
and generic/009. A common _ext4_disable_extent_zeroout()
helper could be added and applied by generic/009 and
_require_seek_data_hole().
2) On some old kernels(e.g. v3.1-v3.6), when vfs recognizes
SEEK_DATA/HOLE flag && ext4 has no extent zeroout tunable
in sysfs, these cases may trigger "sysfs entry not found"
issue. We can add check if extent_max_zeroout_kb exists
on ext4 filesystem.
The extent_max_zeroout_kb is introduced by:
'67a5da564f97 ("ext4: make the zero-out chunk size tunable")'
3) Declare several vars as local in _require_seek_data_hole().
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>
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>
The ACL test shared/051 was very similar to generic/099 which was not
being run and was just removed; most likely the script was copy+pasted
at some point. Since shared/051 has been getting maintained+run and is
not really XFS and UDF-specific, move it to generic, reusing the old
number of 099. One change was required for it to work on other
filesystems: the output of 'find' must be sorted.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This IRIX-specific ACL test was nearly identical to shared/051, which
has been better maintained and will be made a generic test in the next
commit. Therefore, remove the existing generic/099.
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 IRIX and UDF-specific test essentially just created a UDF
filesystem with a specific size. This isn't really useful because there
already are many generic tests that do _scratch_mkfs_sized. So just
delete the test rather than trying to port it to Linux.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
udf/098 was an IRIX and UDF-specific test which tested xattrs. But the
Linux UDF driver doesn't support xattrs, and even if it did there are
already generic xattr tests --- including now generic/097 which is
basically the same test. So just delete udf/098.
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>
This IRIX-specific test did some basic testing of extended attributes.
Port it to Linux; this mainly involved updating it to use the 'getfattr'
and 'setfattr' programs instead 'attr'. Note that although 'attr' is
available on Linux, it's mainly for IRIX compatibility, the man page
recommends against using it on non-XFS filesystems, and it doesn't
support listing user xattrs only. (In the last point it actually
differs from IRIX 'attr', but probably no one cares anymore.) getfattr
also sorts its output by xattr name, so its output will be the same on
all filesystems unlike 'attr -l'.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This IRIX-specific test mainly tested whether a file's capabilities are
cleared when it is written to. Port the test to the Linux libcap tools
and update it to expect the Linux semantics which are a little simpler:
capabilities are always cleared even if the program is root (or has
CAP_FSETID). The test also tests that chmod doesn't affect open file
descriptors; this is mostly unrelated, but keep it in for now.
[eguan: add _require_test_program rule for src/writemod]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
generic/192 would sleep 40 seconds, update a file's atime, and then
fail if the atime was not exactly 40 seconds later. This is
unreliable since things may be slow enough to cause an extra second
to elapse. "Fix" this by allowing for 2 seconds of delay. Also,
while we're at it shorten the sleep to a much more reasonable 5
seconds.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On some buggy kernels, the 'find' command in generic/421 encounters
a "Permission denied" error when trying to search $dir, so it
doesn't find the file it's supposed to. This causes 'cat' to read
from stdin, hanging the test. Quote the argument to cat to make the
test fail right away rather than hanging.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Currently we just have this test run on a whitelist of filesystems,
but it would be best to be able to run it on all of them. The
problem is that a lot of filesystems basically shut down once they
hit metadata errors.
Allow the fsync-err testcase to operate in two different modes. One
mode just does basic testing to ensure that we get an error back on
all fd's when we fsync. The other does a more thorough test to
ensure that we get back 0 on subsequent fsyncs when there hasn't
been any write activity.
For now, we just opt-in to the more thorough testing on certain
filesystems: xfs, ext3 and ext4 on the generic test. All other
filesystems will run in simple mode.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check that the group permission bits of a file are not altered when
setfacl fails. At the time of this patch the test fails for at least
ext2, ext4, jfs and btrfs.
The failure in setfacl is induced by filling the device and setting
as many user attributes to the file as possible. For xfs this is not
enough, and the test will not run.
[eguan replaced setfattr with $SETFATTR_PROG and added enospc group]
Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that a direct IO write works against raid5/6 filesystems and that
after the write operation we are able to read back the correct data
and scrub operations don't find any errors.
This test is motivated by a regression introduced in the merge window
for the 4.13 linux kernel, which was undetected by the current set of
test cases. The issue is fixed by the following patch:
"Btrfs: fix write corruption due to bio cloning on raid5/6"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check that we get -ENXIO if the user calls SEEK_HOLE/SEEK_DATA with
a negative file offset.
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>
Overlayfs hardlink test are expected to fail if overlayfs does not
support the inodes index feature, so don't un them if kernel does
not support the feature.
If the feature is supported, enable it with the index=on mount option
for the hardlink tests, regardless of the build time default determined
by kernel config option CONFIG_OVERLAY_FS_INDEX.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Overlayfs is often used to mount several mounts that share a single
lower dir, but every overlayfs mount should have its own private
upperdir and private workdir.
Overlayfs mount on kernel <= v4.12 does not check if upper/work dirs
are currently in-use by another overlayfs mount on the system and bad
things can happen with such configuration.
Expect EBUSY when trying to mount overlay when:
- Upper dir is in-use by another overlay mount
- Work dir is in-use by another overlay mount
This test does not depend on the overlay index feature.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Verify that overlay is mounted read-only and that it cannot
be remounted rw.
- Mount with no upper dir
- Failure to create work dir
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add tests overlay/022 and overlay/024 to overlay/mount test group.
These tests check behavior of overlay mount cases.
Cc: Xiong Zhou <xzhou@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When overlayfs is configured with CONFIG_OVERLAY_FS_INDEX=y,
workdir from previous overlay mount cannot be reused in a new
overlay mount that uses a different upper dir.
Fix the test to use a different workdir when mounting with a
different upper dir.
This change has not effect on older kernels and overlay
configured without CONFIG_OVERLAY_FS_INDEX.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Bill O'Donnell
Xiao Yang
Zorro Lang
Eric Biggers
Jeff Layton
Ernesto A. Fernández
Filipe Manana
Darrick J. Wong
Amir Goldstein