On Wed, 2010-12-22 at 10:44 +1100, Dave Chinner wrote: > 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. Your change to test 014 looks good to me, and makes the test take about the same time it did previously. Reviewed-by: Alex Elder <aelder@xxxxxxx> > -- > > xfstests: 014 takes forever with large preallocation sizes > > From: Dave Chinner <dchinner@xxxxxxxxxx> > . . . _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
