The option parser only accept options before non-option argument.
Although David Sterba has submitted commit df8c7225ba ("btrfs:
reorder arguments so that options come first"), but this case seems
to be left out.
Signed-off-by: Lu Fengqi <lufq.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send/receive operation works correctly after
moving some directory inode A, renaming a regular file inode B into the
old name of inode A and finally creating a new hard link for inode B at
directory inode A.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix invalid path for link commands"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The cmp command was using the wrong file to perform the comparison.
Use $testdir/beyond instead of $testdir/end.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The -udf parameter for check does not exist. UDF can still be tested
via the configuration parameter FSTYP=udf.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
src/seek_sanity_test assumes that after preallocating space in a
file with fallocate, fseek SEEK_HOLE / SEEK_DATA will still report
the allocated space as a hole. On filesystems without unwritten
extent support, that space will be reported as data, though. On
such filesystems, skip the unwritten extent tests.
Tested on ext4, xfs, and gfs2 + patches for fseek SEEK_HOLE /
SEEK_DATA support.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Both ext4 and xfs have a bug in the page cache scanning code for
SEEK_HOLE / SEEK_DATA in unwritten extents: the start offset isn't
taken into account when scanning a page, so seeking can fail on
filesystems with a block size less than half of the page size. For
example, the following command fails on a filesystem with a block
size of 1k:
xfs_io -f -c "falloc 0 4k" \
-c "pwrite 1k 1k" \
-c "pwrite 3k 1k" \
-c "seek -a -r 0" foo
Like with generic/436, the actual tests are added to seek_sanity_test.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Instead of reporting the preferred block size for I/O as returned by
stat(2) as the allocation size, report the actual allocation size.
Clean things up a little in the process.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
With pending changes for xfs_info/xfs_growfs, the tool
now requires an actual mount point to work properly.
Change this test to test $SCRATCH_MNT not the subdir
beneath it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Bill O'Donnell <billodo@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that subdirectory properly inherits SGID bit even if parent
directory has default ACLs.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Create a file with a hole in the data fork and CoW reservations in the
same region in the CoW fork. Ensure that SEEK_HOLE/DATA find the data.
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>
xfsprogs now ships with a tool to compare its libxfs against a kernel
libxfs. Since the old srcdiff tool assumes dmapi.h (IRIX only) and the
pre-libxfs directory tree layout, fix the test and remove the old tool.
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>
We met a kernel assertion failure recently as below:
XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: fs/xfs/xfs_trans.c, line: 309
Eric Sandeen digged into it and find a good reproducer.
The problem comes when the several IO vectors are copied in, and
it runs into page faults, which stops the copy before all vectors
are copied. XFS sees this as a failed/short write, and so tries
to unmap the blocks & truncate away the pages in xfs_vm_write_end.
generic_perform_write is looping, and comes back around for the
other iovecs, but the page is still there, the buffer head is still
mapped, and so a new delalloc block isn't allocated - and ends up
being allocated at writeback time, despite the fact that we "should"
have accounted for it all at delalloc write time, and trips the
assert.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
For btrfs, we can test how it reports data writeback errors on fsync by
implementing a suggestion from Chris Mason:
Build a filesystem with 2 devices that stripes the data across
both devices, but mirrors metadata across both. Then, make one
of the devices fail and test what it does.
[eguan: add comments about creating btrfs with "-d raid0 -m raid1"]
Cc: Chris Mason <clm@fb.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Ensure that we get an error back on all fds when a block device is
open by multiple writers and writeback fails.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of reporting a
writeback error to only the first fsync caller on the file, it has
the the kernel report them once on every file description that was
open at the time of the error.
This patch adds a test for this new behavior. Basically, open many fds
to the same file, turn on dm_error, write to each of the fds, and then
fsync them all to ensure that they all get an error back.
To do that, I'm adding a new tools/dmerror script that the C program
can use to load the error table from the script. It's also suitable for
setting up, frobbing and tearing down a dmerror device for by-hand testing.
For now, only ext2/3/4 and xfs are whitelisted on this test, since those
filesystems are included in the initial patchset. We can add to that as
we convert filesystems, and eventually make it a more general test.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The writeback error handling test requires that you put the journal on a
separate device. This allows us to use dmerror to simulate data
writeback failure, without affecting the journal.
xfs already has infrastructure for this (a'la $SCRATCH_LOGDEV), so wire
up the ext4 code so that it can do the same thing when _scratch_mkfs is
called.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Linux swapfiles use bmap which has no ability to tell the swap code
that the blocks its reporting aren't actually on the data device.
Therefore, swapon on a realtime file could corrupt random blocks on
the data device, so we must ensure that swapon cannot happen.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The unmerged and impure upper directories may contain invalid
whiteouts when we umount && modify lowerdir(e.g. clean up dir) and
remount overlay. This may lead to whiteouts exposure and rmdir
failure.
This case test impure dir's whiteouts check in ovl_iterate() and
ovl_remove_xxx().
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If generic/397 is executed in an environment with SIGPIPE ignored,
it fails because the 'yes' program prints an error message:
yes: standard output: Broken pipe
yes: write error
This can be reproduced with:
trap '' SIGPIPE; ./check generic/397
Fix it by generating the string of 255 y's using just 'head' and
'tr' instead of 'yes', 'head', and 'tr'.
Although it's not really a good idea to execute xfstests with
SIGPIPE ignored, this is the only test I've noticed where it causes
a problem, so it might as well be fixed in the test.
It would be much nicer to prevent this problem for all tests by
making the 'check' script restore the default SIGPIPE handler. But
that isn't straightforward because bash's 'trap' builtin doesn't
allow un-ignoring signals that were ignored on entry to the shell.
[ eguan added more background infomation to commit log, which is
also from Eric.
I think it's an easy problem for others to run into, since sometimes
processes ignore SIGPIPE because they want to get write errors
instead, but then when doing fork() + exec() they forget to reset
the SIGPIPE handler. Notably, Python got this wrong and it wasn't
fixed until Python 3, so any programs executing the 'check' script
from a Python 2 script will usually get this wrong (see:
https://bugs.python.org/issue1652). And usually everything works
fine but every once in a while there is a weird problem like this
which has to be debugged. ]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send works if we rename some directory inode A
and then rename some file inode B to the name inode A had, for the case
where the directory inode A is an ancestor of inode B in the parent
snapshot.
This issue is fixed by the following patch for the linux kernel:
"Btrfs: incremental send, fix invalid path for unlink commands"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
UDF does not support journalling. Make the appropriate feature test fail
for it.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
A test is creating symlink with a path containing name 1023 characters
long. Such file name is invalid for most filesystems (the limit on file
name lenght is mostly 255 characters) and UDF actually complains about
this and so the test fails. Since the point of this test is to verify
storage of the symlink, change the test to use a valid path where each
component name has only 254 characters.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a regression test for a bug where ->lookup() in an encrypted
directory would incorrectly return EPERM, depending on which inodes
happened to have their keys still cached in memory following removal of
the keyring key. This bug was fixed in v4.12-rc1, v4.9.29, and v4.4.70.
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that an incremental send operation works correctly when an inode A
is renamed, a new hard link added to it and some other inode B is renamed
to the old name of inode A.
The btrfs bug is fixed by the following patch for the linux kernel:
"Btrfs: send, fix invalid path after renaming and linking file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Lu Fengqi
Filipe Manana
Luis Henriques
David Disseldorp
Andreas Gruenbacher
Eric Sandeen
Jan Kara
Darrick J. Wong
Zorro Lang
Jeff Layton
zhangyi (F)
Eric Biggers