From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id q485l8HT066344 for ; Tue, 8 May 2012 00:47:08 -0500 Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id 4GLAdxu5Bp4HFkoO for ; Mon, 07 May 2012 22:47:05 -0700 (PDT) Date: Tue, 8 May 2012 15:47:03 +1000 From: Dave Chinner Subject: Re: fallocate bug? Message-ID: <20120508054703.GG5091@dastard> References: <20120507235955.GE5091@dastard> <20120508044039.GF5091@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Zhu Han Cc: xfs@oss.sgi.com On Tue, May 08, 2012 at 01:10:55PM +0800, Zhu Han wrote: > On Tue, May 8, 2012 at 12:40 PM, Dave Chinner wrote: > > On Tue, May 08, 2012 at 11:24:52AM +0800, Zhu Han wrote: > > > On Tue, May 8, 2012 at 7:59 AM, Dave Chinner > > wrote: > > > > And so now you've triggered the speculative delayed allocation > > > > beyond EOF, which is normal behaviour. Hence there are currently > > > > unused blocks beyond EOF which will get removed either when the next > > > > close(fd) occurs on the file or the inode is removed from the cache. > > > > > > > > > > Close(fd) should be invoked before dd quits. But why the extra blocks > > > beyond EOF are not freed? > > > > The removal is conditional on how many times the fd has been closed > > with dirty data on the inode. > > > > > The only way I found to remove the extra blocks is truncate the file to > > its > > > real size. > > > > If the close() didn't remove them, they will be removed when the > > inode ages out of the cache. Why do you even care about them? > > Our distributed system depends on the real length of files to account the > space usage. That's ..... naive. It's never been valid to assume that the file size is an accurate reflection of space usage, especially as it will *always* be wrong for sparse files. In the same light, you also cannot assume that it is an accurate reflection for non-sparse files because we can do both explicit and speculative allocation beyond EOF which only du will show. Not to mention that metadata is not accounted in the file length, and that can consume a significant amount of space, too. > This behavior make the account inaccurate. The block usage reported by XFS is both accurate and correct. The file size reported by XFS is both accurate and correct. You're "account inaccuracy" is assuming that they are the same. Perhaps you should be using quotas for accurate space usage accounting? Anyway, if you really want to stop speculative delayed allocation beyond EOF, then use the allocsize mount option to control it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs