Test 016 fails with delaylog because it measures log traffic to disk
and delaylog writes almost nothing to the log for the given test. TO
make it work, add sync calls to the work loop to cause the log to be
flushed reliably for both delaylog and nodelaylog and hence contain
the same number of log records.
As a result, the log space consumed by the test is not changed by
the delaylog option and the test passes. The test is not
significantly slowed down by the addition of the sync calls (takes
15s to run on a single SATA drive).
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
The problem was reprted here:
https://bugzilla.redhat.com/show_bug.cgi?id=626244
With the simple test case:
# mkfs.xfs -f -d agsize=16m,size=50g <dev>
# mount <dev> /mnt
# xfs_io -f -c 'resvsp 0 40G' /mnt/foo
Triggering the problem. Turn this into a new xfsqa test so that we
exercise the problem code and prevent future regressions.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
We don't have any coverage of the splice functionality provided by
the kernel in xfstests. Add a simple test that uses the sendfile
operation built into xfs_io to copy a file ensure we at least
execute the code path in xfstests.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
When running test 078 against a 4k logical block sized disk, it fails in
xfs_repair. The problem is that xfs_repair is passed the loopback
filename instead of the actual loop device. This means that it opens
the file O_DIRECT, and tries to do 512 byte aligned I/O to a 4k sector
device. The loop device, for better or for worse, will do buffered I/O,
and thus does not suffer from the same problem. So, the attached patch
sets up the loop device and passes that to xfs_repair. This resolves
the issue on my test system.
Comments are more than welcome.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This test really wants to test partial file-system block I/Os. Thus, if
the device has a 4K sector size, and the file system has a 4K block
size, there's really no point in running the test. In the attached
patch, I check that the fs block size is larger than the device's
logical block size, which should cover a 4k device block size with a 16k
fs block size.
I verified that the patched test does not run on my 4k sector device
with a 4k file system. I also verified that it continues to run on a
512 byte logical sector device with a 4k file system block size.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
When running xfstests on a 4k logical sector device, I ran into a test
failure in test 198. The errors were all due to trying to do 512 byte
aligned I/O on a 4k logical sector device. The attached patch tries to
auto-detect the proper block size if no alignment is specified. If it
fails for one reason or another, it defaults to 4k alignment. This
seems to work fine in my test rig.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
I found that overwriting existing files hides a bug
in ext4 (since fixed). Removing the files before
the test reliably reproduces it.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
I ran into a failure on an ext4 backport which should have
been caught by this test, but 30s wasn't long enough to
hit it reliably. So run a bit longer; it's not in the
quick group anyway.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alex Elder <aelder@sgi.com>
Christoph reported that test 014 went from 7s to 870s runtime with
the dynamic speculative delayed allocation changes. Analysis of test
014 shows that it does this loop 10,000 times:
pwrite(random offset, 512 bytes);
truncate(random offset);
Where the random offset is anywhere in a 256MB file. Hence on
average every second write or truncate extends the file.
If large preallocatione beyond EOF sizes are used each extending
write or truncate will zero large numbers of blocks - tens of
megabytes at a time. The result is that instead of only writing
~10,000 blocks, we write hundreds to thousands of megabytes of zeros
to the file and that is where the difference in runtime is coming
from.
The IO pattern that this test is using does not reflect a common (or
sane!) real-world application IO pattern, so it is really just
exercising the allocation and truncation paths in XFS. To do this,
we don't need large amounts of preallocation beyond EOF that just
slows down the operation, so execute the test with a fixed, small
preallocation size that reflects the previous default.
By specifying the preallocation size via the allocsize mount option,
this also overrides any custom allocsize option provided for the
test, so the test will not revert to extremely long runtimes when
allocsize is provided on the command line.
However, to ensure that we do actually get some coverage of the
zeroing paths, set the allocsize mount option to 64k - this
exercises the EOF zeroing paths, but does not affect the runtime of
the test.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Many of the "count-the-holes" tests (008, 012, etc) do writes that extend the
file and hence allocation patterns are dependent on speculative allocation
beyond EOF behaviour. Hence if we change that behaviour, these tests all fail
because there is a different pattern of holes.
Make the tests independent of EOF preallocation behaviour by first truncating
the file to the size the test is defined to use. This prevents speculative
prealocation from occurring, and hence changes in such behaviour will not cause
the tests to fail.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
When compiling "fiemap-tester.c" in my environment, I am
getting complaints at the first reference to "uint64_t"
in <linux/fs.h>. This simple patch resolves that.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
xfs_quota can output different amounts of spaces when it is trying to align
its output. This can cause output mismatch on several systems in test case 108.
Filter all the consecutive spaces in xfs_quota output to just one space,
making the test case independent of the alignment.
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test case 237 checks for setfacl output. The setfacl can use both
relative address or absolute address for filename.
Following patch ignores the unnecessary part of absolute address and
therefore the test case can pass on systems that output absolute
address.
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test cases 051 and 067 use getfacl with option -n. This works well on newer systems but older acl package know only its longer version: --numeric.
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Test 245 only checks to see if the rename returned EEXIST, but according to the
rename(2) manpage, ENOTEMPTY is also a valid result, which is in fact what Btrfs
returns. So just filter the output for ENOTEMPTY so that either EEXIST or
ENOTEMPTY will pass the test. It's not pretty I know, but I couldn't really
figure out a good way to get an either/or output to compare. With this fix
Btrfs now passes 245.
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
A customer reported a problem:
If a process is using mmap to write to a file on an
ext4 filesystem while another process is using direct
I/O to write to the same file the first thread may
receive a SIGBUS during a page fault.
A SIGBUS occurs if the page fault tries to access a
page that is entirely beyond the end of the file but
in this test case that should not be happening.
Signed-off-by: Lachlan McIlroy <lmcilory@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Test case 223 constantly fails because the variable carrying mkfs
options is not being reinitialized.
Test calls function _scratch_mkfs_geom repeatedly in for loop without
cleaning the MKFS_OPTIONS variable. Since _scratch_mkfs_geom only
appends options to the variable, MKFS_OPTIONS looks like this in 5th
iteration:
MKFS_OPTIONS="-bsize=4096-b size=4096 -d su=8192,sw=4-b size=4096 -d
su=16384,sw=4-b size=4096 -d su=32768,sw=4-b size=4096 -d
su=65536,sw=4-b size=4096 -d su=131072,sw=4"
It is also easy to see that _scratch_mkfs_geom does not append leading
space when it appends the variable.
Following patch fixes the issue for me and based on my testing does not
break any other test case:
Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Per Posix renames over non-empty directories should fail, but hfsplus used to
allow this (and corrupt the filesystem while doing so).
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Add a helper to check if the filesystem supports sparse files. This is
used to guard tests that exercise sparse file functionality and would
take forever on filesystems that have to zero all blocks on extending
truncates.
Unfortunately there's no good way to autodetect this functionality, so
just implement it as a blacklist for now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Christoph Hellwig suggested that a function similar to the common
"_filter_scratch" function ought to be created to handle filtering
of the TEST_DIR and TEST_DEV variables. This patch implements that.
The name "_filter_test" seems like it might suggest it does
something different, so I'm calling this one "_filter_test_dir".
This unfortunately makes the "test" and "scratch" functions have
different naming conventions, but I guess we should be accustomed to
that by now (consider "TEST_DIR" and "SCRATCH_MNT").
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Dave Chinner
Jeff Moyer
Eric Sandeen
Eric Sandeen
Alex Elder
Zhong, Xin
Boris Ranto
Josef Bacik
Lachlan McIlroy
Christoph Hellwig
Christoph Hellwig