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>
As of now xfstests decides if a filesystem supports attributes by trying
to write one to the mount point. For some reason this fails on reiserfs,
making it impossible to run tests that _require_attrs.
Fix this by checking against $TEST_DIR/syscalltest instead of $TEST_DIR.
This is probably what was intended, since the syscalltest file is touched
right before running attr. It is also consistent with how the check for
acl support is done.
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>
Add support for jfs in _scratch_mkfs_sized. Fix the block size in
4096, which seems to be the only option in jfs_mkfs.
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>
The helper is used to test if a specific filesystem feature can
be enabled. Currently only implemented testing overlayfs features.
Overalyfs features (e.g. redirect_dir, index) are configurable from
Kconfig (the build default), by module parameter (the system default)
and per mount using the mount option ${feature}=[on|off].
The helper is going to be used by overlay tests, which depend
on the inodes 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>
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>
Test a regression in XFS where we blow out a transaction reservation if
we create a big file, share every other block, and delete the first
file. There's nothing particularly fs-specific about this stress test,
so put it in generic.
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/297 formats the scratch device with test specific mkfs options
that limit the use of certain mount options (i.e., if logbsize !=
256k). If an incompatible mount option is set, the mount fails but
the test proceeds to run against the root filesystem.
Update xfs/297 to fail if the mount of the scratch device fails for
whatever reason.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
In commit d55123c080 ("generic/247: filter out expected XFS warnings
for mixed mmap/direct I/O"), _scratch_unmount was removed from
generic/095 and added to generic/247. But actually generic/095 *should*
be unmounting SCRATCH_DEV; and generic/247 should be unmounting
TEST_DEV, not SCRATCH_DEV, since it doesn't use a scratch device (it was
failing if SCRATCH_DEV was not defined). Fix it.
[eguan: the original bug was introduced by me not Brian, as I
removed _scratch_unmount from wrong test]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
nlink of overlay inode could be dropped indefinitely by adding
un-accounted lower hardlinks underneath a mounted overlay and
trying to remove them.
The simplest way to understand this test is this:
Imagine that you have a tool (e.g. xfs_db) with which you can add
hardlinks, without changing the value of nlink stored on-disk for
the inode. This is exactly what this test does when it adds lower
hardlinks underneath a mounted overlay.
Commit 5f8415d6b87e ("ovl: persistent overlay inode nlink for
indexed inodes") fixes this issue, although the issue was never
exposed in any released kernel.
With overlayfs indexed copy up and without the fix, the test
triggers WARN_ON(inode->i_nlink == 0) in drop_link().
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
nlink of overlay inode should account for the union of lower
and upper hardlinks.
persistent overlay union nlink is stored in an extended attribute
on the upper inode.
In order to test persistent overlay nlink accounting, the test is
repeated with both warm and cold dentry/inode cache.
[eguan: add comments on what fields report_nlink prints]
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Two tasks make a modification concurrently on two hardlinks of a
large lower inode. The copy up should be triggered by one of the
tasks and the other should be waiting for copy up to complete. Both
copy up targets should end up being upper hardlinks and both
metadata changes should be visible in both hardlinks.
With kernel <= v4.12, hardlinks are broken on copy up, meaning that
copy up is performed independetly and the resulting upper copy up
targets each have only one of the the metadata changes visible.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that when two lower hardlinks are copied up, they end up
as two upper hardlinks of the same upper inode.
Drop caches before copy up so there is no knowledge of the
copied up hardlink in inode/dcache.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test checks if overlayfs hardlinks are preserved across
copy up. Check if they are preserved also after copy up and
mount cycle.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Eric Biggers
Jeff Layton
Ernesto A. Fernández
Filipe Manana
Darrick J. Wong
Amir Goldstein
Brian Foster