X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBM2Ysk1148332 for ; Tue, 21 Dec 2010 20:34:54 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay2.corp.sgi.com (Postfix) with ESMTP id F04A53040D2; Tue, 21 Dec 2010 18:36:49 -0800 (PST) Received: from [127.0.0.1] ([128.162.232.50]) by cf--amer001e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Dec 2010 20:29:38 -0600 Subject: Re: [PATCH 06/34] xfs: dynamic speculative EOF preallocation From: Alex Elder Reply-To: aelder@sgi.com To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com In-Reply-To: <20101221234412.GC4907@dastard> References: <1292916570-25015-1-git-send-email-david@fromorbit.com> <1292916570-25015-7-git-send-email-david@fromorbit.com> <20101221151511.GA26127@infradead.org> <20101221214240.GB4907@dastard> <20101221234412.GC4907@dastard> Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Dec 2010 20:29:37 -0600 Message-ID: <1292984977.2408.359.camel@doink> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Dec 2010 02:29:38.0161 (UTC) FILETIME=[1479E610:01CBA180] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean 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 > -- > > xfstests: 014 takes forever with large preallocation sizes > > From: Dave Chinner > . . .