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>
diff may skip comparing content of files with identical st_ino/st_dev.
Overlayfs stat(2) may return same st_dev/st_ino for hardlink copy ups,
but it does not mean that read(2) will return the same content.
Convert the test to output hardlink files content to golden output
instead of using diff.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Use helpers to records and check inode numbers so we can repeat
the same test after each hardlink 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>
On xfs filesystem, the following patch fixed system crash caused by
this race, but it introduced the __xfs_get_blocks() warning when the
race occurred:
04197b3 ("xfs: don't BUG() on mixed direct and mapped I/O")
On upstream kernel, the fix patch was cleared by:
acdda3a ("xfs: use iomap_dio_rw")
When the fix patch was applied and not cleared(e.g, on RHEL7.4),
this case triggered the __xfs_get_blocks() warning as expected.
Moreover, generic/095 may reproduce the same warning occasionally.
So we could add __xfs_get_blocks() into _filter_xfs_dmesg.
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>
It turns out that there was a bug in xfs_bmap_count_blocks wherein
the block count returned would count or not count delalloc blocks
depending on the fork format. This is a bug that is easily exposed
via scrub, so check the output of that function here -- the buggy
version of the function produces online fsck errors.
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>
The ext4 online scrub program is no longer under active development,
so remove all the test code that tried to use it.
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>
Ernesto A. Fernández
Filipe Manana
Darrick J. Wong
Amir Goldstein
Brian Foster
Eric Biggers
Xiao Yang