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); 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@xxxxxxxxxx> --- 014 | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/014 b/014 index a0c0403..e6e0a6f 100755 --- a/014 +++ b/014 @@ -50,6 +50,12 @@ _supported_os IRIX Linux _require_sparse_files _setup_testdir +# 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. +umount $TEST_DIR +_test_mount -o allocsize=64k + echo "brevity is wit..." echo "------" _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
