If NIS is active on a test target system, additional password and
group file information is available via their respective databases
in NIS. Currently, some tests assume that /etc/passwd and /etc/group
are the only places to find this information.
This patch causes both the local database and the NIS database (if
one is likely to be present) to be consulted for needed information.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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>
Provide generic function _check_quota_usage for checking whether quota usage
matches the space used and use it in proper tests.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test 214 and 236 use the same file names for test files in the TEST
filesystem and don't check/create clean initial test state. Hence if
you run 214 then 236, 236 will fail with:
+link: cannot create link `/mnt/test/ouch2' to `/mnt/test/ouch': File exists
+ctime: 1277076527 -> 1277076527
+Fatal error: ctime not updated after link
Ensure that both tests clean up after themselves properly and also
ensure a clean state before they start.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
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>
By default xfs_io uses a buffer size of 4096 bytes. On test 226,
the result is that the test runs much slower (at least an order
of magnitude) than it needs to.
Add a flag to the "pwrite" command sent to xfs_io so it uses
larger buffers, thereby speeding things up considerably.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
The test for fallocate was broken because it used $TEST_DIR/$tmp.io. Because
$tmp is usually something like /tmp/1234 or /mnt/1234 the file cannot be
created and xfs_io fails regardless of existance of fallocate support. Moreover
the subsequent message parsing decides that fallocate is actually supported
because it does not expect this message.
Fix the test to not use $tmp.
Signed-off-by: Jan Kara <jack@suse.cz>
For all 2.6 kernels presence of quota support in kernel can be detected by
checking /proc/sys/fs/quota. This is actually more reliable than trying to
mount a filesystem with quota options (for example because SCRATCH_DEV does
not have to contain a filesystem type we are going to test).
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>
There are some spots in the "group" file where test numbers have
groups listed after a '#' character, clearly intending for those
groups to be commented out. But the way the group list gets
generated that commenting doesn't work, and in fact these tests
explicitly *are* included in such commented-out groups.
This patch fixes that, stripping out all comments (which start
with a '#' character and end with a newline) from the file before
building the set of test numbers for a group.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-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>
According to Documentation/filesystems/fiemap.txt, If fm_extent_count
is zero, then the fm_extents[] array is ignored (no extents will be
returned), and the fm_mapped_extents count will hold the number of
extents needed.
This is broken by commit 97db39a1f6f69e906e98118392400de5217aa33a.
So add this test case in fiemap tester to avoid future regression.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Reviewed-by: Dave Chinner <david@fromorbit.com>
Set up autoconf to find the correct headers and compat libraries for
debian squeeze, and massage the includes to ensure the right headers get
included. Also fix a compile warning that was emitted now that it is being
compiled.
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Alex Elder
Eric Sandeen
Jan Kara
Christoph Hellwig
Dave Chinner
Shi Weihua
Amit Arora
Tao Ma
Dave Chinner