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

[Christoph Hellwig <hch@infradead.org>]

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@lst.de>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs