[Top] [All Lists]

Re: [PATCH v4 1/8] xfs: add EOFBLOCKS inode tagging/untagging

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH v4 1/8] xfs: add EOFBLOCKS inode tagging/untagging
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Fri, 28 Sep 2012 16:40:44 -0400
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20120928070401.GH25626@dastard>
References: <1348767952-24229-1-git-send-email-bfoster@xxxxxxxxxx> <1348767952-24229-2-git-send-email-bfoster@xxxxxxxxxx> <20120928070401.GH25626@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
On 09/28/2012 03:04 AM, Dave Chinner wrote:
> 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 <bfoster@xxxxxxxxxx>
> 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.....

Sure. I skimmed through the first set and it didn't seem like a major
conflict. I'll rebase against the v3 xfssyncd set for my next version.


> Cheers,
> Dave.

<Prev in Thread] Current Thread [Next in Thread>