This tests whether the file or directory overwritten by rename is properly
removed (nlink is zero).
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by a bug found in btrfs when replaying a
directory from the fsync log. The issue was that if a directory
entry is both found in the persisted metadata and in the fsync
log, at log replay time the directory got set with a wrong i_size.
This had the consequence of not being able to rmdir empty
directories (failed with errno ENOTEMPTY).
This was fixed in btrfs with the following linux kernel patch:
Btrfs: fix directory recovery from fsync log
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS allocates extra indirect blocks for delayed allocation extents at
write time. When delalloc extents are split, the existing indirect block
reservation was historically divided up evenly among the new extents
even though the overall requirement for two extents could exceed the
requirement for the original. Repeated delalloc extent splits ultimately
leads to extents with 0 indirect blocks and in turn leads to assert
failures in XFS.
Add a test to stress indirect block reservation for delayed allocation
extents. The test converts a single delalloc extent to many and operates
on the remaining extents to detect or trigger potential problems.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
XFS had a data corruption problem where writeback of pages to unwritten
extents would fail to run unwritten extent conversion at I/O completion.
This causes subsequent reads of written, but unconverted regions to
return zeroes. This occurs on sub-page block size filesystems when
writeback contends for the inode lock (e.g., with a file writer).
Add a test that creates the conditions to reproduce the data corruption
and detect it by looking for unwritten extents after all said extents
have been overwritten.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test exposed a problem with XFS where it failed to write back a
partial page correctly during a fcollapse operation. This left a
stray dirty buffer on the page, and hence invalidation of the page
then failed of the fcollapse returned an EBUSY error.
Make this a generic test so that we can ensure that all filesystems
handle the case correctly. Test case originally worked out and
written by Brian Foster.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test exposed a problem with mapped writes to the tail page of a
file in XFS and potentially ext4. Eric did all the hard work of
taking the bug report and generating the reproducable test case on
ext4. Make it a generic test so that we can ensure that all
filesystems handle the case correctly.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test exposed a problem with mapped writes to the tail page of a
file in XFS. Hence make it a generic test so taht we can ensure that
all fielsystems handle the case correctly.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is motivated by a btrfs issue where a ranged fsync would
prevent a subsequent fsync from persisting any extents that were
dirty at the time of the first fsync but that were outside the range
of that first fsync (which should have been persisted by the second
fsync).
This bug in btrfs is fixed by the following linux kernel patch:
Btrfs: fix fsync data loss after a ranged fsync
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check defrag utility on file with large number of fragments, from 20 to 2000.
2000 fragments means that b+tree will have at least two index blocks.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
By closing the file descriptor before calling io_destroy, you pretty
much guarantee that the last put on the ioctx will be done in interrupt
context (during I/O completion). This behavior has unearthed bugs in
the kernel in several different kernel versions, so let's add a test to
poke at it.
The original test case was provided by Matt Cross. He has graciously
relicensed it under the GPL v2 or later so that it can be included in
xfstests. I've modified the test a bit so that it would generate a
stable output format and to run for a fixed amount of time.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
The following kernel commit introduced a race condition that causes
getcwd(2) to return "/" instead of correct path
232d2d6 dcache: Translating dentry into pathname without taking rename_lock
Jan Stancek hit it once when building ltp and Mikulas Patocka could
hit it by running lvm2 test suite. Please refer to this thread
https://www.mail-archive.com/ltp-list@lists.sourceforge.net/msg17896.html
These commits fixed the bug
ede4ceb prepend_path() needs to reinitialize dentry/vfsmount/mnt on restarts
f650080 __dentry_path() fixes
Cc: Artem Savkov <asavkov@redhat.com>
Cc: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Run 8 processes writing 1k files to seperate files in seperate dirs to
hit ENOSPC on small fs with little free space. Loop for 100 iterations.
Regression test for
34cf865 ext4: fix deadlock when writing in ENOSPC conditions
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Having just removed the largeacl test from the shared ACL test,
reintroduce the same test as an generic test so that we can
handle the different limits in supported ACL count appropriately
across different filesystems and different configurations within
filesystem types.
Filesystems have to add support to _acl_get_max to run
this test - the default behaviour right now is to throw a
notrun error like this:
generic/026 14s ... [not run] ext4 does not define maximum ACL count
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check with RENAME_EXCHANGE flag. This flag indicates that the
source and destination files are to be exchanged.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check with RENAME_NOREPLACE flag. This flag indicates that the
rename must fail if the target of the rename exists.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Check with zero flags. This is what rename(2) and renameat(2) now
call, so this actually tests the behavior of these syscalls as well.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
There are couple of tests in shared directory which really should be
made generic, so move it. It is mostly collapse range tests, which
really can be generic to make super we test every file system which adds
collapse range support.
Here is what we're moving in this commit.
shared/001 -> generic/021
shared/002 -> generic/022
shared/003 -> generic/012
shared/004 -> generic/016
shared/005 -> generic/017
shared/218 -> generic/018
shared/305 -> generic/019
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This is based on xfs/242. This is very similar to ext4/001 however this
test has some tweaks to make it work test zero range on generic file
system. This includes turning off ext4 extents zeroout and disabling
the test for xfs on systems where PAGE_SIZE > 4096.
It is testing extent tree manipulation with fallocate zero range
operation.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Add test for fallocate zero range at block boundary. This is similar to
the test xfs/290 however this one is generic and we're testing different
block sizes as well - namely 1k, 2k, 4k and 64k. Note that we're not
creating file systems with given block size buy rather test all 4
options.
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Tests the noatime, relatime, strictatime and nodiratime mount
options.
There is an extra check for Btrfs to ensure that the access time is
never updated on read-only subvolumes. (Regression test for bug
fixed with commit 93fd63c2f001ca6797c6b15b696a484b165b4800)
Signed-off-by: Koen De Wit <koen.de.wit@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs was screwing up rename+fsync, add some regression tests for
the various scenarios it was screwing up.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Btrfs had some issues with fsync()'ing directories and fsync()'ing
after renames. These three new tests cover the 3 different issues
we were seeing. This breaks out the dmflakey stuff into a common
helper to be shared between generic/311 and this new test.
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
This test is based on generic/273, a regression test for commit
9a3a5da xfs: check for stale inode before acquiring iflock on push
On unpatched kernel, rm processes would hang.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
This test is motivated by an issue found by a btrfs user, addressed
and described by the following Linux kernel patch:
https://patchwork.kernel.org/patch/3046931/
The steps to reproduce the issue on btrfs are the following:
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt
$ mkdir /mnt/acl
$ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl
$ getfacl /mnt/acl
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::---
$ mkdir /mnt/acl/dir1
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
After unmounting and mounting again the filesystem, getfacl returned the
expected default ACL for the subdirectory:
$ umount /mnt/acl
$ mount /dev/loop0 /mnt
$ getfacl /mnt/acl/dir1
user::rwx
group::rwx
other::---
default:user::rwx
default:group::rwx
default:other::---
This means that the underlying ACL xattr was persisted correctly but
the in memory representation of the inode had (incorrectly) a NULL ACL.
[rjohnston: renumbered test to 319]
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Miklos Szeredi
Filipe Manana
Brian Foster
Dave Chinner
Dave Chinner
Dmitry Monakhov
Jeff Moyer
Eryu Guan
Lukas Czerner
Christoph Hellwig
Koen De Wit
Josef Bacik
Filipe David Borba Manana