Add _require_scratch_duperemove which validates that the file system
supports duperemove. This allows us to move three tests from shared/
to generic/. This means these tests will automatically adapt when
duperemove supports other file systems. Tests moved are:
shared/008 --> generic/559
shared/009 --> generic/560
shared/010 --> generic/561
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
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>
The tests shared/{001,003,004,272} test behaviour around the ext4's
journal. As such, they are pointless to run on ext2, and ext3 no
longer is in kernels newer than 4.3. (And most enterprise
distributions have been using ext4 to support the ext3 file system;
that capability has been around since 2.6.33.) So we can move these
tests out of shared and into the ext4 class of tests:
shared/001 --> ext4/036
shared/003 --> ext4/037
shared/004 --> ext4/038
shared/272 --> ext4/039
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This case is used to cover xfsprogs bug fixed by commit b136f48b19a5
("xfs_quota: fix false error reporting of project inheritance flag
is not set") at first. Then test more behavior when project
ineritance flag is set or removed.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In some setup, there could be extra attrs printed, like selinux.
They are breaking golden output and irrelevant for this test.
So focus on the attr we are testing on to avoid false alarm.
Print the output to .full for debug.
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
With the new copy on write functionality it's possible to reserve so
much COW space for a file that we end up overflowing i_delayed_blks.
The only user-visible effect of this is to cause totally wrong i_blocks
output in stat, so check for that.
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>
In late 2016, tests overlay/01[6-8] where merged to track the
state of several ilong standing posix compliance issues on overlayfs.
This practice was somewhat of an exception for xfstests project,
which more often merges tests for issues that are expected to be
resolved in the short term.
Over the years, some test cases have been fixed and more tests
where created to cover the remaining issues (e.g. overlay/04[34]).
Currently, the only failing test from this category is overlay/061
which covers item b) in the "Non-standard behavior" section of
Documentation/filesystems/overlayfs.txt.
Since there is no clear design, roadmap nor allocated resources
to resolve this remaining issue, the test is removed from the
"auto" and "quick" groups, following a suggestion that Darrick
has made for a similarly long failing generic test.
The test was added to the new "posix" group, to allow testing
for posix compliance.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test as well that hole punch operations that affect a single file block
also update the file's mtime and ctime.
This is motivated by a bug a found in btrfs which is fixed by the
following patch for the linux kernel:
"Btrfs: add missing inode version, ctime and mtime updates when
punching hole"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we fsync a file, evict its inode, unlink it and then fsync
its parent directory, after a power failure the file does not exists.
This is motivated by a bug found in btrfs, which is fixed by the following
patch for the linux kernel:
"Btrfs: fix fsync not persisting dentry deletions due to inode evictions"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This new test implements verification for the per-directory
case-insensitive feature, as supported by the reference
implementation in Ext4.
Signed-off-by: Lakshmipathi.G <lakshmipathi.ganapathi@collabora.co.uk>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
[Rewrite to support feature design]
[Refactor to simplify implementation]
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a flavor of test generic/545 with FS_IOC_FSSETXATTR ioctl
instead of FS_IOC_SETFLAGS ioctl.
Overlayfs gained support for FS_IOC_FSSETXATTR ioctl in v5.2-rc4
with buggy capability check. This change fixed the problem:
ovl: fix wrong flags check in FS_IOC_FS[SG]ETXATTR ioctls
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
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>
Right at the beginning of the test we are unmonting the scratch device,
however at this point the device was never mounted, so the unmount fails
with an error message like the following:
umount: /home/fdmanana/btrfs-tests/scratch_1: not mounted
Which is not expected by the golden output and therefore causes the test
to fail.
Since the device/mount point was not mounted yet in the test, and since
the test framework unmounts the scratch device after each test finishes,
just remove the call to _scratch_unmount.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For the t_open_tmpfiles tests that run multiple jobs in parallel,
limit ourselves to half of file-max for all jobs combined,
so that we don't OOM the test machine.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test creates a file system with a 1k block size. Since there
are no architectures with a 1k page size, the test file system can
never be mounted with DAX enabled, causing the test to fail.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Yang Xu<xuyang2018.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Depending on filesystem, copying from active swapfile may be allowed,
just as read from swapfile may be allowed.
Note the kernel fix commit in test description.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Move some tests to the copy_range group so they are distinct
from the copy group which refers to xfs_copy tests.
[Amir] Revert copy past EOF behavior change
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Check that if we write some data to a file, its inode gets evicted
(while its parent directory's inode is not evicted due to being in
use), then we rename the file and fsync it, after a power failure
the file data is not lost.
This currently passes on xfs, ext4 and f2fs but fails on btrfs. The
following patch for btrfs fixes it:
"Btrfs: fix data loss after inode eviction, renaming it, and fsync it"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The current btrfs/048 test-case did not check the behavior of
properties with options like compression and with the compression
level supplied.
Add test cases for compression with compression level as well so we
can be sure we don't regress there.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Theodore Ts'o
Zorro Lang
Murphy Zhou
Darrick J. Wong
Amir Goldstein
Filipe Manana
Murphy Zhou
Lakshmipathi.G
Johannes Thumshirn