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>
There are a number of tests that use a shell function called
"filter_scratch" or "_filter_scratch" in order to have the actual
scratch device or mount point show up in test output with a symbolic
name. There are two sets, each following a slightly different
convention. Put a common _filter_scratch function definition in
"common.filter" and have all test scripts use that instead.
Choosing one of the two conventions meant that a few test output
files had to be changed.
In addition, add a call to _filter_scratch to test 185, and update
its output accordingly.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Do a _notrun in 225 if we get EOPNOSUPP back from FIEMAP instead
of failing the test.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Add a new helper to check if extended attributes are supported. It
errors out if any of the attr tools are not found, or if a filesystem
does not support setting attributes.
Remove the opencoded checks for the attr tools from various tests
now that we do them in common code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Even if the kernel has quota support built in most filesystems still
don't support it. As there's no good way to find out if a filesystem
supports quotas hardcode the list of filesystems that do support
quotas.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Skip ACL tests if we get EOPNOTUPP back from the acl calls. This is
the error code we get on a kernel that does support the xattr system
calls, but does not support the attributes used to handle Posix ACLs.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Alex Elder <aelder@sgi.com>
Minor bits to wrap up this series.
- Bumped up the number of blocks read at once from 10 to 256
- Shorten remaining long lines
- Re-factor findblock()
- Get rid of global variable "nvalid"
- Add a few more comments
- Give all global symbols static scope
- Update the copyright message
- Various other minor formatting changes.
Signed-off-by: Alex Elder <aelder@sgi.com>
Acked-by: Dave Chinner <david@fromorbit.com>
Move the argument parsing code out of main() and into a separate
parseargs() routine. The name of the target file for the test
is returned by parseargs() if no error occurs.
Signed-off-by: Alex Elder <aelder@sgi.com>
Acked-by: Dave Chinner <david@fromorbit.com>
Make readblks() a bit more readable by computing a few things
into local variables, and pulling out a few of the comma-separated
expressions that were previously in the for loop headers.
Signed-off-by: Alex Elder <aelder@sgi.com>
Acked-by: Dave Chinner <david@fromorbit.com>
Dave Chinner
Alex Elder
Zhong, Xin
Boris Ranto
Josef Bacik
Lachlan McIlroy
Christoph Hellwig
Christoph Hellwig