Test that if we have a file with a hole, do a mix of direct IO and
buffered writes to it and truncate the file to a size that lies in
the middle of the hole, after unmounting and mounting again the
filesystem, the file has a correct size and no data loss happened.
This test is motivated by a bug found in btrfs when used with the
no-holes feature (i.e. MKFS_OPTIONS="-O no-holes") which is fixed by
the following patch for the linux kernel:
Btrfs: fix data loss after truncate when using the no-holes feature
[eguan: add _require_odirect]
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test cover linux commit 7ae8fd0, when mnt_group_id=0, it means
this mount no peers. But this bug treat two zero mnt_group_id as
peers. And it cause a crash by dereference a NULL address.
As below, the crash will happen when mount fs on "B/mnt1/mnt2":
shared New FS shared
-----------------------[A/mnt1]----------------------
| | |
| bind | bind |
[C/mnt1]--[slave C]<------[shared A]------>[slave B]--[B/mnt1]
|
|
[B/mnt1/mnt2]
(New FS)
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case will do function test for mount --make-* operations, it
will verify below state transition:
------------------------------------------------------------------------
| |make-shared | make-slave | make-private |make-unbindab|
--------------|------------|--------------|--------------|-------------|
|shared |shared |*slave/private| private | unbindable |
| | | | | |
|-------------|------------|--------------|--------------|-------------|
|slave |shared | **slave | private | unbindable |
| |and slave | | | |
|-------------|------------|--------------|--------------|-------------|
|shared |shared | slave | private | unbindable |
|and slave |and slave | | | |
|-------------|------------|--------------|--------------|-------------|
|private |shared | **private | private | unbindable |
|-------------|------------|--------------|--------------|-------------|
|unbindable |shared |**unbindable | private | unbindable |
------------------------------------------------------------------------
This case uses fsstress to produce a small random load, to make sure
basic operations on the mountpoints won't cause hang or panic etc.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case will do function test for mount bind operation, it will
verify below semantics:
---------------------------------------------------------------------------
| BIND MOUNT OPERATION |
|**************************************************************************
|source(A)->| shared | private | slave | unbindable |
| dest(B) | | | | |
| | | | | | |
| v | | | | |
|**************************************************************************
| shared | shared | shared | shared & slave | invalid |
| | | | | |
|non-shared| shared | private | slave | invalid |
***************************************************************************
This case usees fsstress to produce a small random load, to make
sure basic operations on the bind mountpoints won't cause hang or
panic etc.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On btrfs, if a large dio write (>=128MB) got splitted, the
outstanding_extents assertion would complain. Note that
CONFIG_BTRFS_ASSERT is required.
Regression test for
Btrfs: adjust outstanding_extents counter properly when dio write is split
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test mkfs against thin provision device, which has very small
backing size and very big virtual size. mkfs should return error
when it hits EIO.
Signed-off-by: Boyang Xue <bxue@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Regression test which targets two nasty ext4 bugs in a logic which
shifts extents:
1) 14d981f468a1 ("ext4: Include forgotten start block on fallocate insert range")
Test tries to insert many blocks at the same offset to reproduce
the following layout on ext4:
block #0 block #1
|ext0 ext1|ext2 ext3 ...|
^
insert of a new block
Because of an incorrect range first block is never reached,
thus ext1 is untouched, resulting to a hole at a wrong offset:
What we got:
block #0 block #1
|ext0 ext1| ext2 ext3 ...|
^
hole at a wrong offset
What we expect:
block #0 block #1
|ext0 ext1|ext2 ext3 ...|
^
hole at a correct offset
2) 2b3864b32403 ("ext4: do not polute the extents cache while shifting extents")
Extents status tree is filled in with outdated offsets while doing
extent shift, that leads to wrong data blocks. That's why md5sum
of a result file is being checked after each block insert.
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Cc: "Theodore Ts'o <tytso@mit.edu>"
Cc: Eryu Guan <eguan@redhat.com>
Cc: linux-ext4@vger.kernel.org
Cc: fstests@vger.kernel.org
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test reproduces a bug in XFS where a getxattr of an existing
xattr returns failure due to a race with a setxattr that causes
inode attribute fork conversion.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test helps to validate clamping and mount behaviors
according to supported file system timestamp ranges.
Note that the test can fail on 32-bit systems for a
few file systems. This will be corrected when vfs is
transitioned to use 64-bit timestamps.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Verify correct d_type values of dir entries.
This test does NOT require that file system support the filetype
feature. It verifies that either all file types are reported as
DT_UNKNOWN or that all file types are reported correctly.
For fs for which we know how to test the filetype feature (xfs|ext*)
verify getting DT_UNKNOWN IFF filetype feature is disabled.
Special dir entries . and .. MAY be reported as DT_UNKNOWN IF
filetype feature is disabled (ext4), but MAY also be reported as
DT_DIR in this case (xfs).
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS kernel code had a bug where GETNEXTQUOTA-type
quotactls requesting an ID near UINT_MAX could overflow
and return 0 as the "next" active ID.
This test checks that by creating an active quota near
UINT_MAX, then asking for the next one after it.
The proper answer is ENOENT, but if we wrap we'll return
ID 0.
This also changes test-nextquota.c so that it checks
both GETNEXTQUOTA and XGETNEXTQUOTA even if one fails;
it stores the failure conditions and returns 1 if either
of them fails.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add an xfstest which can detect some basic crypto mistakes that would
reduce the confidentiality guarantee provided by filesystem encryption.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add an xfstest which verifies that the filesystem forbids operations
that would violate the constraint that all files in an encrypted
directory tree use the same encryption policy.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test accessing encrypted files and directories, both with and
without the encryption key.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add an xfstest which verifies the kernel performs basic validation
of the encryption policy structure.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Several kernel bugs were recently fixed regarding the constraints
for setting encryption policies. Add tests for these cases and a
few more.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If a file size limitation is set, underlying filesystem should not
break the limit and exceed the max file size.
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This patch introduces a new testcase to test some small truncations
to check inline_data and its cached data are truncated correctly at
the same time.
The inline_data feature was introduced in ext4 and f2fs as follows.
ext4 : http://lwn.net/Articles/468678/
f2fs : http://lwn.net/Articles/573408/
The basic idea is embedding small-sized file's data into relatively
large inode space.
In ext4, up to 132 bytes of data can be stored in 256 bytes-sized inode.
In f2fs, up to 3.4KB of data can be embedded into 4KB-sized inode block.
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This patch adds case to test fsync and fdatasync with power-cuts.
The rule to check is:
1) fsync should guarantee all the inode metadata after power-cut,
2) fdatasync should guarantee i_size and i_blocks at least after
power-cut.
Note that, in XFS, it allocates more blocks when doing writes, so it
should close the file before fsync in order to get actual i_blocks
after power-cut. Or, it needs to do truncate the file with a
specific size to turn it off at the beginning.
Suggested-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There have been a couple of logic bugs in `btrfs_get_extent()` which
could lead to spurious -EEXIST errors from read or write. This test
exercises those conditions by having two threads race to add an
extent to the extent map.
This is fixed by Linux commit 8dff9c853410 ("Btrfs: deal with
duplciates during extent_map insertion in btrfs_get_extent") and the
patch "Btrfs: deal with existing encompassing extent map in
btrfs_get_extent()"
(http://marc.info/?l=linux-btrfs&m=147873402311143&w=2).
Although the bug is Btrfs-specific, nothing about the test is.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Multi-threads freeze/unfreeze maybe trigger some bugs, e.g: panic,
hang or data corruption etc. It does't check the return value of
freeze/unfreeze, but it tries to make sure fsstress won't run fails,
and no any other bugs happen.
[eguan: add comment on why we check _scratch_mount failure]
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
generic/314 no longer tests POSIX ACLs. It only tests the SGID bit.
Therefore, it should not be in the acl group anymore.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Filipe Manana
Zorro Lang
Christoph Hellwig
Theodore Ts'o
Liu Bo
Boyang Xue
Roman Pen
Brian Foster
Deepa Dinamani
Amir Goldstein
Eric Sandeen
Eric Biggers
Eryu Guan
Jaegeuk Kim
Omar Sandoval