xfs
[Top] [All Lists]

Re: [PATCH 3/4] xfs: reclaim all inodes by background tree walks

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 3/4] xfs: reclaim all inodes by background tree walks
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 11 Jan 2010 05:19:53 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1263167508-9346-4-git-send-email-david@xxxxxxxxxxxxx>
References: <1263167508-9346-1-git-send-email-david@xxxxxxxxxxxxx> <1263167508-9346-4-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.19 (2009-01-05)
On Mon, Jan 11, 2010 at 10:51:47AM +1100, Dave Chinner wrote:
> We cannot do direct inode reclaim without taking the flush lock to
> ensure that we do not reclaim an inode under IO. We check the inode
> is clean before doing direct reclaim, but this is not good enough
> because the inode flush code marks the inode clean once it has
> copied the in-core dirty state to the backing buffer.
> 
> It is the flush lock that determines whether the inode is still
> under IO, even though it is marked clean, and the inode is still
> required at IO completion so we can't reclaim it even though it is
> clean in core. Hence the requirement that we need to take the
> flush lock even on clean inodes because this guarantees that the
> inode writeback IO has completed and it is safe to reclaim the
> inode.
> 
> With delayed write inode flushing, we coul dend up waiting a long
> time on the flush lock even for a clean inode. The background
> reclaim already handles this efficiently, so avoid all the problems
> by killing the direct reclaim path altogether.

Looks good,


Reviewed-by: Christoph Hellwig <hch@xxxxxx>

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