On Wed, Dec 22, 2010 at 08:42:40AM +1100, Dave Chinner wrote:
> On Tue, Dec 21, 2010 at 10:15:11AM -0500, Christoph Hellwig wrote:
> > This patch causes tesr 014 to take ~ 870 seconds instead of 6, thus
> > beeing almost 150 times slower on mt 32-bit test VM, so I'll have to NAK
> > it for now.
> It's not the speculative preallocation changes - ithey are just
> exposing some other regression. That is, using MOUNT_OPTIONS="-o
> allocsize=4k" gives the previous behaviour, while allocsize=512m
> gives the same behaviour as the dynamic preallocation.
> The dynamic behaviour is resulting in megabyte sized IOs being
> issued for random 512 byte writes (which is wrong), so I'm tending
> towards it being a regression caused by the reecent writeback path
> changes. I'll dig deeper today.
Ok, it's not a recent regression - it's the fact that the test is
writing and truncating to random offsets so the file size is
constantly changing resulting in xfs_zero_eof() writing huge amounts
of zeros into preallocated extents beyond EOF. The patch below
explains the situation and the change to the test to avoid
the extended runtime.
Ultimately, we probably need to change xfs_zero_eof() to allocate
unwritten extents rather than write megabytes of zero for
speculative allocation beyond EOF. However, I'm going to worry about
that when (if) we come across applications that trigger this issue.
xfstests: 014 takes forever with large preallocation sizes
From: Dave Chinner <dchinner@xxxxxxxxxx>
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);
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
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
Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
014 | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/014 b/014
index a0c0403..e6e0a6f 100755
@@ -50,6 +50,12 @@ _supported_os IRIX Linux
+# ensure EOF preallocation doesn't massively extend the runtime of this test
+# by limiting the amount of preallocation and therefore the amount of blocks
+# zeroed during the truncfile test run.
+_test_mount -o allocsize=64k
echo "brevity is wit..."