This replicates file corruption we've seen with qemu-kvm when
we use if=virtio,cache=none,aio=native for IO to a sparse
ext4- or xfs-hosted file, and the partitions/filesystems
within that file image are not block-aligned. (think sector
63 here...) This results in AIO IOs not aligned to the
filesystem blocks.
This test modifies aiodio_sparse2.c to add an option to start
the file IO at an offset.
When we do 4k writes to a 16k file in 2 threads, starting
at offset 512, we get 0s interspersed in the file where they
should not be:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 |................|
*
00001000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001200 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 |................|
....
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
When Christoph and I were discussing bulkstat coherency on IRC, we
realised that inode lookup from bulkstat was not actually looking up
the inode allocation btree in xfs_imap() before reading the inode
buffer from disk in xfs_iread(). Bulkstat uses the same lookup
mechanism as handle validation to avoid shutting down the filesystem
if inode numbers that point to non-inode buffers (i.e. invalid) are
passed in the handle.
The problem with this is that when we delete inodes from disk and we
remove the inode chunk (i.e. deallocate inodes) we mark both the
inodes in memory and the cluster buffer as stale, thereby preventing
it from being written back to disk. The result of this is that some
number of inodes remain on disk looking like allocated, in use
inodes (i.e. di_mode is not zero).
Hence if we get a cold cache lookup from a stale handle that
references such an inode, we can read the inode off disk even though
it has been deleted because we don't check if the inode is allocated
or not. If the inode chunk has not been overwritten, then the inode
read will succeed and the handle-to-dentry conversion will not error
out like it is supposed to. The result is that stale NFS filehandles
and open_by_handle() will succeed incorrectly on unlinked files for
cold cache lookups.
This is a bug that has been present ever since the inode chunk
deletion code was implemented. This test exercises the problem and
documents the hoops you have to jump through to reproduce it.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Run fsx (and also several fsx threads in parallel) and verify that
quota accounting is correct after they finish.
Signed-off-by: Jan Kara <jack@suse.cz>
This is an adapted version of the reproduced in OSS BZ #874, which
shows file corruption when using the extent size hint.
Signed-off-by: Geoffrey Wehrman <gwehrman@sgi.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add a new testcase to the xfstests suite to check if fallocate respects
the limit imposed by RLIMIT_FSIZE (can be set by "ulimit -f XXX") or
not, on a particular filesystem.
Signed-off-by: Amit Arora <aarora@in.ibm.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
This test aims to recreate the conditions that caused xfs_fsr to
corrupt inode forks. The problem was that the data forks between the
two inodes were in different formats due to different inode fork
offsets, so when they swapped the data forks the formats were
invalid.
This test generates a filesystem with a known fragmented freespace pattern and
then abuses known "behaviours" of the allocator to generate files
with a known number of extents. It creates attributes to generate a
known inode fork offset, then uses a debug feature of xfs_fsr to
attempt to defrag the inode to a known number of extents.
By using these features, we can pretty much cover the entire matrix of inode
fork configurations, hence reproducing the conditions that lead to corruptions.
This test has already uncovered one bug in the current kernel code, and the
current fsr (with it's naive attribute fork handling) is aborted on a couple of
hundred of the files created by this test.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Test writing and removing a file in a loop; filesize is 64m,
filesystem size is 256m. Loop 16 times each for buffered and
direct.
ext4 hits enospc after a couple loops.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Alex Elder <aelder@sgi.com>
Preliminary fiemap testing support based on a test util written by
Josef Bacik.
For now it's only run with preallocation disabled, because xfs has a
tendency to fill in holes with data blocks (EOF prealloc stuff I
think) and similar for explicit preallocation, so this is breaking
the preallocation tests for now, when it finds a "data" block where
it expects a preallocated block.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
When we deplete the reserve block pool or receive an error during
delayed allocation, we currently toss the page away. If that page
has delayed allocation extents on it, we can fail to remove them and
leave stale delayed llocation extents lying around on the inode.
This can, in certain circumstances, trigger errors later on when the
stale delalloc extent it found again, including tripping a BUG().
Exercise this failure path so that we get code coverage of the fix
that prevents stale delalloc mappings from being left on the inode
when pages are tossed.
This is based on a test case supplied by Lachlan McIlroy.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
053 and 077 can be generic w/ a little tweaking.
Also change 077's filler to something more likely
to be on a random system under test, and add it
to the enospc group.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
A first-cut test to ensure that files are well-aligned on filesystems
with stripe geometry.
Several sizes of stripe units are mkfs'd, and then files are written
and fallocated in various multiples of those stripe sizes.
Each file is checked to ensure that the first block is
stripe-aligned.
(Ideally, for any fragmented files, we should ensure that each
fragment start is well-aligned, but this does not do that yet)
(slightly unrelated: don't send scratch mkfs output to /dev/null,
we'd like to see mkfs output and direct it to $seq.full - this
more or less matches _scratch_mkfs_xfs behavior and doesn't
break any tests that I can see)
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tests 018, 081 and 082 read the contents of the log and assume that the
contents will always be the same. They are trying to ensure that the
contents of the log don't change for a given fixed load.
This has several problems - high level changes to the filesystem and
VFS code can change the order and contents of the log. Changes to
the way we sync the filesystem will change the contents of the log.
background writeback occurring in the middle of the test will change
the contents of the log by allowing the tail to move. Even changes
to the default mkfs parameters can break them!
The tests also assume that unmount leaves a dirty log behind. We've
fixed lots of problems in sync and the unmount paths over recent
times, so now a clean unmount leaves a clean log behind. That is,
there is nothing left in the log print output for these tests to
check. IOWs, major surgery is required for these tests to be
returned to their former break-when-something-changes behaviour.
However, these tests are a maintenance nightmare. They spend more
time broken and failing than they do passing, and then it's not long
before they get broken again. They have to cover all sorts of
different permutations of log configurations and that will continue
to grow and increase the complexity of making these tests continue
to work. And to top it all off, I can't remember a bug actually ever
being found by these tests. Hence I think we should just stop using
them altogether.
So this patch deprecates 018, 081 and 082 rather than fixes them.
It introduces a "deprecated" test group and puts them in it. That
means the tests can still be run on older systems where they may
have some use, but will not be run automatically any more, nor
will any attempt be made to keep them up to date or working.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Otherwise it fails to match the golden output. Also add
the test to the auto group so that it is run regularly now
that the growfs problems are fixed.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We have very little fsr test coverage in the test suite right now.
042 is the only test that runs it, and it only defragments a single
file.
Improve the coverage by simply running xfs_fsr of the test
filesystem. This gives xfs_fsr a wide variety of inodes to try to
defragment. A simple test like this would have tripped over the
attr2 fork offset problems in the swap extents ioctl long ago
thanks to the varied nature of inodes the test suite leaves around
in this filesystem.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Add a test to check if we update the ctime properly if not updating
the mtime in futimens.
Uses a C program contributed by Eric Blake <ebb9@byu.net>.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <david@fromorbit.com>
By mounting the filesystem with quotas enabled in 087 we exercise the
replay of the quota log items in this tests, which we otherwise don't
test in xfstests. OSS bugzilla #855 is an example of something caught
by this.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <david@fromorbit.com>
Also, add an expected output, not sure how that went missing!
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Eric Sandeen
Christoph Hellwig
Dave Chinner
Shi Weihua
Jan Kara
Amit Arora
Eric Sandeen
Dave Chinner