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 q8S72ii5196711 for ; Fri, 28 Sep 2012 02:02:44 -0500 Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id im4ojcAM2IItR4G5 for ; Fri, 28 Sep 2012 00:04:02 -0700 (PDT) Date: Fri, 28 Sep 2012 17:04:01 +1000 From: Dave Chinner Subject: Re: [PATCH v4 1/8] xfs: add EOFBLOCKS inode tagging/untagging Message-ID: <20120928070401.GH25626@dastard> References: <1348767952-24229-1-git-send-email-bfoster@redhat.com> <1348767952-24229-2-git-send-email-bfoster@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1348767952-24229-2-git-send-email-bfoster@redhat.com> 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: Brian Foster Cc: xfs@oss.sgi.com On Thu, Sep 27, 2012 at 01:45:45PM -0400, Brian Foster wrote: > Add the XFS_ICI_EOFBLOCKS_TAG inode tag to identify inodes with > speculatively preallocated blocks beyond EOF. An inode is tagged > when speculative preallocation occurs and untagged either via > truncate down or when post-EOF blocks are freed via release or > reclaim. > > The tag management is intentionally not aggressive to prefer > simplicity over the complexity of handling all the corner cases > under which post-EOF blocks could be freed (i.e., forward > truncation, fallocate, write error conditions, etc.). This means > that a tagged inode may or may not have post-EOF blocks after a > period of time. The tag is eventually cleared when the inode is > released or reclaimed. > > Signed-off-by: Brian Foster Apart from the fact this conflicts with my xfssyncd killing patchset and xfs_sync.c no longer exists, it looks fine. Can you rebase this on top of my patch series? Mostly it is simply making your changes to xfs_icache.c rather than xfs_sync.c as that's where all this inode cache radix tree walking code is now..... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs